Bugzilla – Full Text Bug Listing
| Summary: | Order of deletes change causes issues for cycles with an untriggered 1-M and PrivateOwned | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Tom Ware <tom.ware> | ||||||
| Component: | Eclipselink | Assignee: | Tom Ware <tom.ware> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | eclipselink.orm-inbox | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Tom Ware
If we choose to address this, we will likely want to consider making the behavior that allows this optional so people with out this particular sequence of mappings can still take advantage of the performance benefits of the change referenced above. It should be possible to work around this by ensuring the mapping between B and C is instantiated. CollectionMapping contains: mustDeleteReferenceObjectsOneByOne If this is true, the issue will go away. A fix that will allow a workaround is to simply add a setter for this method and have a user call it through a customizer. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=350618 for change that will allow a workaround. Initial target 2.3.1 Doing some more triage with the goal of deciding whether/how to address this issue. Some initial thoughts: 1. It is very difficult for us to detect the situation that results in this issue. I can only recreate with a combination of privateOwned mappings that use parts of the primary key as foreign keys in relationships. 2. As mentioned above, technically, by the JPA specification, the link between C and A should be severed by the user prior to deleting A. 3. Since we successfully deleted these kinds of mappings in 2.1, we should address this in some way 4. I suggest we address this in two ways - Make mustDeleteReferenceObjectsOneByOne more easily user-manipulable. i.e. make it so it can be set directly in a customizer rather than requiring a pre-login event - Create a persistence unit level flag that causes all reference objects to be deleted one by one. We will have to discuss what the default value of this flag will be. The above changes will allow users depending on the 2.1 behavior to continue to function while users that adhere more stricty to the JPA standard will get the performance benefit of the delete all. Created attachment 201101 [details]
proposed fix - trunk
After much discussion, we decided that we would revert the default of deleting 1-Ms as a collection. We will revert to deleting the entities individually except in the case where the target of the relationship has either no relationships of a single relationship that represts a backpointer to the source.
As a result, users that encouter this bug will now work by default.
The attached patch represents what will be checked into our trunk (2.4) stream. It contains an annotation and eclipselink-orm.xml support that allows mappings to be set to use the collection-based delete.
Users of 2.3.x will have to use a customizer to reenable the collection based delete.
Above changes checked into 2.3.1 and trunk. @DeleteAll and <delete-all/> config is only available in trunk. Reviewed by James Sutherland and Guy Pelletier Tested with JPA LRG and Core LRG Added testing to PrivateOwned model for core change in both streams Added additional testing for Annotation and XML to PrivateOwned model and to eclipselink-orm model in trunk stream Created attachment 203408 [details]
Added change on top of poatch
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |