Community
Participate
Working Groups
The following change caused a change in our treatment of deleting for cycles that involve multiple PrivateOwned relationships with at least one being PrivateOwned. https://bugs.eclipse.org/bugs/show_bug.cgi?id=324341 An example of a situation that could cause the problem is: A - OneToOne<privateOwned> - B B - OneToMany<privateOwned><Lazy&Uninstantiated> - C C - OneToOne - A Prior to 2.2, deleteing an instance of A involved in this relationship would cause the delete order to be C - A - B Starting with 2.2, A is deleted first causing a constraint issue with the relationship between C and A The issue occurs because we are now relying on the preDelete method on OneToManyMapping to do a DeleteAll for the relationship between B and C. The problem is that the preDelete method will not be triggered until B is deleted and that does not occur until we attempt to delete A. Strictly according to the JPA specification, this is NOT a bug. The relationship from C to A is required to be severed before A can be deleted. The argument that this is a bug is only that the behavior has changed - something that we can debate.
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
