Bugzilla – Full Text Bug Listing
| Summary: | Wrong PK Identification for inherited entity when using embeddable data object (not ePK) in both subclasses | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Sergey Ponomarev <serggt1> | ||||||||
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P2 | CC: | eclipselink.orm-inbox, tom.ware | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 186684 [details]
project with entities and testcase
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines The EclipseLink bug is a result of the way we handle Descriptors for Embeddables. Initially, a descriptor is created that is shared amoung all embeddables. At our session initialization time, that descriptor is cloned and the clone is modified with the values that are particular to the mapping that is using it. The behavior will be different for Embeddables that are part of ElementCollections vs. Embeddables that are used as Embedded. In the case listed in this bug, an Embeddable is being used both as part of an ElementCollection and directly as an Embedded. Depending on the initialization order, it will function as one or the other -> yielding different errors in each case. The case in this bug occurs when the Embedded version is processed first by our processing of the metadata. In this case, we are treating the dscripor as if it were part of an ElementCollection (last-in wins). In that case, we treat all the fields as the primary key and as a side effect of some other code, copy those keys to the owning-descriptor. Workaround is likely to fix the primary key for the owning descriptor post-login. Created attachment 204701 [details]
proposed fix 2.3 stream
Created attachment 204706 [details]
proposed fix - trunk
The fix makes it so that people that are going to share Embeddables should set the descriptor as aggregate (rather than aggregate collection). At descriptor clone time, AggregateCollectionMapping will change aggregate descriptors to be aggreateCollection. Also changed some checks throughout eclispelink to be more specific about what they are testing for to allow easier searching for places where it is relevant whether something is aggregate vs. aggregate colleciton Fixed in trunk and 2.3 as described above Reviewed by Andrei Ilitchev Tested with Core and JPA LRG Added test to InheritedTestModel The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
Build Identifier: EclipseLink 2.1.1 There is a class hierarchy: abstract Geozone - CircleGeozone - PolygonGeozone Both circle and polygon geozones use embeddable object GeoPoint, and it becomes PK for PolygonGeozone for some reason. Maven project with unit test is included, it passes well on Hibernate. Reproducible: Always Steps to Reproduce: 1. lookup for CircleGeozone using find() 2. lookup for PolygonGeozone using find(), it breaks