You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Issue
When nesting multiple
@MappedCollection
ofList
s 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 multiplekeyColumn
s of the@MappedCollection
s 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 forSet
s.When using
@MappedCollection
for a Set nested within another@MappedCollection
(e.g. LList
), theSet
isn't stored correctly. ThekeyColumn
of the encapsulatingList
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 PersonFor a nested
@MappedCollection
of typeList
the behaviour is that thekeyColumn
s of all parent collections are taken over. However in the provided example usingSet
,skill.position_in_queue
isn't populated in the database.The aforementioned behaviour doesn't change by adding
keyColumn
to the@MappedCollection
of theSet
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
Intended behaviour
The behaviour shouldn't be inconsistent between
List
s andSet
s (or at least be well documented).First I thought that this behaviour should also apply to
Set
s. This would work for aSet
nested in another collection, but not for aSet
nested within aSet
(as far as I understand there would be no way to differentiate between the innerSet
s)It seems to me as if the intention was that every entity with a
@MappedCollection
must specify an@Id
column and theidColumn
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
@MappedCollection
sSet
sList
(andMap
?). This change sounds like it could be breakingI hope this issue isn't to verbose and but comprehensible. I'm happy to clarify if needed
The text was updated successfully, but these errors were encountered: