Skip to content

Inconsistent @MappedCollection behaviour for Set vs. List #2061

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MoellJ opened this issue May 21, 2025 · 1 comment
Open

Inconsistent @MappedCollection behaviour for Set vs. List #2061

MoellJ opened this issue May 21, 2025 · 1 comment
Assignees
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement

Comments

@MoellJ
Copy link

MoellJ commented May 21, 2025

Issue

When nesting multiple @MappedCollection of Lists any only specifying the @Id for the root, saving and loading work fine. An entity on a lower level is identified using the id of the root and multiple keyColumns of the @MappedCollections in between.

I'm unsure if this is indented behavior or if every intermediary entity should have an @Id. I didn't even question if this was intended until I figured out that it doesn't work for Sets.

When using @MappedCollection for a Set nested within another @MappedCollection (e.g. LList), the Set isn't stored correctly. The keyColumn of the encapsulating List isn't populated in the resulting table entry.

Example project

To see an example of this, checkout https://github.com/MoellJ/SpringJDBCMappedCollectionBug (and it's tests)

Details on example

RestaurantQueue
├── Person (via @MappedCollection(idColumn = "queue_id", keyColumn = "position_in_queue") in RestaurantQueue)
│ └── Skill (via @MappedCollection(idColumn = "queue_id") in Person

For a nested @MappedCollection of type List the behaviour is that the keyColumns of all parent collections are taken over. However in the provided example using Set, skill.position_in_queue isn't populated in the database.

The aforementioned behaviour doesn't change by adding keyColumn to the @MappedCollection of the Set
As is expected from documentation and Javadoc. See:

* The column name for key columns of {@link List} or {@link Map} collections in the corresponding relationship table.

Intended behaviour

The behaviour shouldn't be inconsistent between Lists and Sets (or at least be well documented).
First I thought that this behaviour should also apply to Sets. This would work for a Set nested in another collection, but not for a Set nested within a Set (as far as I understand there would be no way to differentiate between the inner Sets)

It seems to me as if the intention was that every entity with a @MappedCollection must specify an @Id column and the idColumn attribute should refer to this. (Just a guess)
This is not currently the case case (´idColumn` might refer to the id of the grand-parent if parent doesn't have an id).

I'm unsure if this issue should only result in improved documentation

  • or changing behaviour of @MappedCollections Sets
  • or restricting the possibly unintended behaviour of using a grand-parent id for List (and Map?). This change sounds like it could be breaking

I hope this issue isn't to verbose and but comprehensible. I'm happy to clarify if needed

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 21, 2025
@schauder schauder self-assigned this May 22, 2025
@schauder schauder added the type: enhancement A general enhancement label May 22, 2025
@schauder
Copy link
Contributor

We should add documentation and add a check that results in an error if there are nested Sets without @Id

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants