Skip to content

fix(core): resolve compound primary key component metamodels to their columns#217

Merged
zantvoort merged 1 commit into
mainfrom
fix/compound-pk-component-metamodel
Jul 9, 2026
Merged

fix(core): resolve compound primary key component metamodels to their columns#217
zantvoort merged 1 commit into
mainfrom
fix/compound-pk-component-metamodel

Conversation

@zantvoort

Copy link
Copy Markdown
Collaborator

Problem

Per-component metamodels of a compound primary key (VetSpecialty_.id.specialtyId, Metamodel.of(VetSpecialty.class, "id.specialtyId"), and the leaves returned by Key#flatten()) fail template and predicate resolution with Column not found for metamodel, even though the generated metamodel classes expose these nodes. See #216 for the full analysis.

Root cause

ModelFactory#createColumns registers every component column of a record-typed @PK under the key's group metamodel (via the keyMetamodel override), so the column map carries no entry for the component's own canonical form. The component node is a scalar leaf, so the inline prefix fallback does not apply. Plain non-key inline records keep their own metamodels, which is why Owner_.address.city resolves while compound key components do not.

Fix

When the key's group metamodel overrides a component column's addressing identity, the component's own metamodel is retained as the column's secondaryMetamodel. ModelImpl#initColumnMap already indexes secondary metamodels (the mechanism foreign keys use for their referenced-PK mirror), so component lookups resolve without any change to the lookup path:

  • getColumns(id.specialtyId) → the single component column,
  • getColumns(id) → all key columns, exactly as before (the group registration is untouched),
  • primary metamodel identity is unchanged, so PK-based WHERE compilation, value binding, and the ambiguity check are unaffected,
  • depth-general: compound-PK components of foreign-key-expanded relations resolve too, since the retained metamodel carries the full path.

Tests

  • ModelImplIntegrationTest#testVetSpecialtyCompoundPkComponentColumns: component lookups return their distinct single columns and the compound lookup still returns both.
  • TemplatePreparedStatementIntegrationTest#testSelectCompoundPkComponent: a SELECT DISTINCT template using a component metamodel compiles and executes.

Full storm-core suite passes.

Fixes #216

… columns

Component columns of a record-typed @pk are registered under the key's
group metamodel so compound lookups return all key columns. The
component's own metamodel is now retained as the column's secondary
metamodel, which the column map already indexes, so the per-component
metamodels exposed by generated metamodel classes and Key#flatten()
resolve to their individual column in templates and predicates.

Fixes #216
@zantvoort zantvoort merged commit b6a5fc8 into main Jul 9, 2026
7 checks passed
@zantvoort zantvoort deleted the fix/compound-pk-component-metamodel branch July 9, 2026 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compound primary key component metamodels fail template resolution ("Column not found for metamodel")

1 participant