You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@grails.apache.org by "borinquenkid (via GitHub)" <gi...@apache.org> on 2026/10/10 19:57:03 UTC

[PR] Hibernate 7: load an inverse hasMany whose composite identifier is not declared in name order [grails-core]

borinquenkid opened a new pull request, #16574:
URL: https://github.com/apache/grails-core/pull/16574

## Problem

An inverse `hasMany` on an entity with a composite identifier that is not declared in name order loads no elements. With `composite('zeta', 'alpha')` and `static hasMany = [kids: Kid]` (`Kid belongsTo = [parent: Parent]`), `parent.kids` is empty while `kid.parent` loads. With `composite('alpha', 'zeta')` it works. In the three level `PrbGrand`/`PrbMiddle`/`PrbLeaf` chain, `grand.middles` and `middle.leaves` loaded empty in every registration order.

`BidirectionalOneToManyLinker.link` copies the columns of the to-one side, which the composite foreign key alignment of #16539 has put in identifier order already, and then called `key.sortProperties()`, which applied the owner identifier's permutation a second time. The collection key therefore ended up in a different column order than the to-one key (`prb_middle_grand_parent_zeta, prb_middle_grand_parent_alpha, prb_middle_name` against `..._alpha, ..._zeta, ..._name`), so the identifier values were bound to the wrong columns. The analysis is jdaugherty's, from the review of #16539.

## Impact

Hibernate 7 on 8.0.x: any inverse `hasMany`/`oneToMany` whose owner has a composite identifier declared out of name order silently loads an empty collection. Saving and the to-one side are unaffected. Single column identifiers and identifiers declared in name order are unaffected, and the DDL does not change.

## Fix

The linker marks the copied key as sorted instead of re-sorting it, so the collection key ends with exactly the column order and types of the to-one side. The collection's second pass can run before the deferred `CompositeForeignKeySecondPass` of the to-one side (two of the registration orders of the chain), so the linker first calls the idempotent `alignWithReferencedIdentifier` on the to-one side, which does nothing when it is aligned already. The result is independent of the registration order. `BidirectionalOneToManyLinker` takes the `CompositeIdentifierToManyToOneBinder` for this.

## Tests

Red before the fix, green after (all 14 new iterations failed with the collection empty: the simple parent/kid case in both registration orders, the chain in all 6 and the hub children in all 6):

- `InverseHasManyCompositeIdentifierOrderSpec`: the previously `@PendingFeature` case is now a plain feature over the 2 registration permutations of `IhmParent`/`IhmKid`; it saves, reloads in a new session and asserts the kids, and that the collection key columns equal the to-one foreign key columns in order. The name-order case still passes (3 tests).
- `CompositeForeignKeyRegistrationOrderSpec`: two new features. The three level chain over the 6 permutations of `PrbGrand`/`PrbMiddle`/`PrbLeaf` asserts `grand.middles` and `middle.leaves` load after save and a session clear and are keyed like their to-one side. The hub layout (`PrbHub`, multi-column nested part between plain parts, `PrbHubChild`) over the 6 permutations asserts the children load and are keyed like the hub key. The spec now runs 49 iterations.
- `BidirectionalOneToManyLinkerSpec`: two new unit features (the copy is marked sorted and Hibernate does not permute it again; the to-one side is aligned once, before the key copies its columns). `CollectionKeyBinderSpec` and `CollectionSecondPassBinderSpec` use the new constructor.
- `:grails-data-hibernate7-core:test` passes in full (3714 tests, 0 failures, 15 skipped), `checkstyleMain` and `codenarcMain` are clean. `CompositeForeignKeyColumnTypesSpec` and the existing foreign key and DDL specs are unchanged and pass.

Fixes #16565

🤖 Generated with [Claude Code](https://claude.com/claude-code)

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org