Community
Participate
Working Groups
Build Identifier: Eclipselink 2.1.1.v20100817-r8050 Unlike sets, lists can have duplicate members at different positions. Given a many-to-many association modelled as a list with an @OrderColumn, Eclipselink shows various sorts of incorrect behaviour when this list contains duplicate entries, e.g. [0] A [1] C [2] B [3] C [4] D I start with an empty database. In a first transaction, I create 1 parent and 4 child entities where the parent has a list of 5 children with one duplicate as indicated. On commit, the expected database rows are inserted. In a second transaction, I use em.find() to load the parent entity I've just created. I expect to see a SELECT statement, but Eclipse seems to take the entity from its cache, and I don't know how to turn this off. em.clear() after commit does not help. On committing this second transaction, Eclipselink inserts another tuple [3] C into the join table. In a third transaction, I query my parent entity with a fetch join, like select distinct p from Parent p join fetch p.children Now the child list has 4 items (A, C, B, D), where 5 would have been correct and 6 might have been expected after the previous problem. Leaving out "distinct" from this query, I get a result set with 6 times the same parent entity containing the same list of 4 children. See also bug 325053 for the model I'm using or http://hwellmann.blogspot.com/2010/09/jpa-20-ordered-collections.html for some more background on this example. Reproducible: Always
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
Deferring this bug. The reason this is not implemented yet is because it is difficult to make this work for mappings without relation tables and therefore mappings with relation tables have not yet been addressed to keep things consistent.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink