Decide on an approach for updating supported Trino model versions

[murakami-ta]

Background

The latest supported model version is 351 (lib/trino/client/model_versions/351.rb). The QueryInfo payload structure in recent Trino releases has diverged from 351, and some fields can no longer be mapped onto the model, so they are inaccessible from the client. We'd like to update the supported model versions to fix this.

That said, the current modelgen/ auto-generation does not work as expected against recent Trino. For example, some structures are now defined as Java record classes, and there are other structural changes as well, so the generation script itself needs a few updates before it can target a modern version.

Before starting work on supporting a newer model version, I'd like to settle on an approach.

Options

Option 1: Jump to the latest Trino (e.g., 481) and update modelgen to match the latest source layout

• Gets us to the latest in one step.
• However, if modelgen is tuned only to the latest, adding any intermediate version (between 351 and the latest) later via modelgen may become difficult.

Option 2: Bump model versions incrementally (e.g., stepping through 351 → 370 → ... → latest)

• Smaller diffs per step and easier to bisect which Trino release broke modelgen.
• Downside: the immediate pain is on current Trino, so this delays the fix.

Option 3: Add model versions manually without using modelgen

• Reduces the cost of maintaining and reviewing modelgen.
• Since this is no longer auto-generated, a way to verify that the output actually works becomes more important. But with AI Agent assistance the real cost should stay manageable.

Proposal

Planning to use an AI Agent is a reasonable idea, and I think option 3 is the best choice.

Feedback welcome.

[miniway]

Thanks for raising the issue.

Technically, having a model class for every version is ideal. Specially, QueryInfo and its dependents keep changing.
But to reduce the effort of managing the model class, I would suggest Option 1 for actual benefit and future management.

When we need an intermediate version, ex 450, we could create a topic branch, then might need to backport from the latest modelgen changes.