Align Resource Group Tables with Trino v476

[yardenc2003]

Description

This PR updates the resource groups–related tables to match the schemas used by Trino (v476).

Additional context and related issues

Since version 14, automatic database migrations have been enabled in the gateway (I believe in this PR).
This causes conflicts (different Flyway migration checksums) with the automatic migrations triggered during Trino’s startup. As a result, when sharing the database between the gateway and one or more Trino instances, migration immediately fails.

If we decide to enable only the gateway migrations, we must ensure the schemas match Trino’s. Otherwise, it fails due to missing columns. This PR addresses that schema alignment.

Refers this issue.

a Few Disclaimers

• I believe we need to disable one of the migrations (either Trino's or the gateway's) or at least document this. Currently, it does not work with the default configuration if resource groups are enabled and Trino shares the database with the gateway.
• I have not verified compatibility with older Trino versions that haven’t updated their schemas while the gateway has, only with v476 for the different db implementations.
• I had to reduce the maximum length of the environment column in exact_match_source_selectors in Oracle to match Trino’s schema. This change might be unsafe and prone to failures.
• I have not updated either the UI forms for resource groups/selectors creation or the underlying SQL statements (DAO classes). I wasn’t sure if this effort was worthwhile, given that this feature is about to be removed from the gateway and the existing implementation has issues updating via the UI.

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
(X) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text.

[oneonestar]

We should allow gateway to be used with old and new version of Trino (or a mix of both).
I'd prefer disable the migration on Resource Group tables.

[xkrogen]

I'd prefer disable the migration on Resource Group tables.

+1 -- the owner of these tables is the Trino Coordinator, not the GW. The GW should not attempt to perform schema changes on these tables.

We should allow gateway to be used with old and new version of Trino (or a mix of both).

+1 the GW should be able to handle multiple schema versions of this DB

[mosabua]

I agree that we should disable automatic updates from Trino Gateway.

I would go one step further .. and we agreed on that already .. Trino Gateway should not have UI to manage the resource group data .. it should move to the Trino UI, specifically the new preview UI.

Separately if we need some sort of concept and tooling around resource use in Trino Gateway (and we do) we should implement something new that works properly for multiple clusters and more.

[mosabua]

So what is the plan here? Are the migrations already disabled by default and we can bring this change in as it stands .. or do we need to disable the migration from Trino Gateway as well as part of this PR in a separate commit?

[yardenc2003]

So what is the plan here? Are the migrations already disabled by default and we can bring this change in as it stands .. or do we need to disable the migration from Trino Gateway as well as part of this PR in a separate commit?

Flyway table migration is still enabled by default - https://github.com/trinodb/trino-gateway/blob/main/gateway-ha/src/main/java/io/trino/gateway/ha/config/DataStoreConfiguration.java#L23

Also, regarding the PR changes - how do we ensue the shared table schemas stay aligned with those in Trino?

[mosabua]

Can you rebase this PR so we can merge .. and then ideally as a follow up we remove the resource group tables with a migration and also remove the UI for it.

[yardenc2003]

@mosabua I think these changes should not be merged as you are planning on removing the resource groups feature from the gateway anyway. The right thing to do is probably abandon the resource-groups-related tables by the gateway and let trino manage them. For now I manage to overcome the incompatibility caused by the resource groups tables flyway migration, by using a separate databases for trino & gateway so they don't interfere each other, and the gateway resource groups tables are empty as they don't have affect on the trino clusters.

Would you like me to open a PR for removing the resource groups feature from gateway completely or is it blocked by something else?

[mosabua]

If you could create a PR that removes the resource group stuff that would be AWESOME @yardenc2003