Inconsistent @MappedCollection behaviour for Set vs. List

[MoellJ]

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:

spring-data-relational/spring-data-relational/src/main/java/org/springframework/data/relational/core/mapping/MappedCollection.java

Line 49 in d411be4

* 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

[schauder]

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