Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] control order of em.remove() calls

There is a bug logged for this,

https://bugs.eclipse.org/bugs/show_bug.cgi?id=315141

Please vote for the bug and add your usecase to the bug.

If you mark the relationship as @PrivateOwned or in JPA 2.0 set
orphanRemoval=true in your OneToMany this should resolve the issue (and is
probably what you want anyway).

A workaround is to flush() after each remove call to force your order to be
used.

In general on commit() EclipseLink writes/deletes objects in an optimal
order that is based on mapping constraints.  The issue you are encountering
is because the relationship is to the same class, EclipseLink handles this
for writes, but not currently for deletes.



Christian Menz wrote:
> 
> Dear all,
> 
> I have an issue I can't solve.
> My data structure has a parent child relation, like..
> 
> class A {
> 
> 	A parent;
> 
> 	List  children (cascade=ALL)
> }
> 
> Now I want to remove a part of the tree. As far as I understand the order
> of the delete statements is essential. What I actually do is a recursive
> method that deletes all the instances beginning from the leaves.
> 
> This looks more or less like :
> 
> remove(A a) {
> 
>        recursiveRemove(a);
>        a.parent.children.remove(a);
> 
> }
> 
> removeRecursive(A a) {
> 
> 	for all children of a {
> 		removeRecursive(a);
> 		a.parent.children.remove(a);
> 	}
> 
> 	entityManager.remove(a);
> }
> 
> I know the entityManager.remove() calls come in in the correct (leaf
> first) order, but JPA seems to execute in another order. It tries to
> delete the parent first, which causes a violation of the constraint.
> 
> Am I completely on the wrong path or is there a way to control execution
> order of JPA-statements for such parent/child relations? I thought that
> should be the case anyways.. :)
> 
> BTW. when just letting JPA remove the data with em.remove(rootA) I get the
> same problem. That is actually why I implemented the recursive call.
> 
> Thank you very much for your support.
> 
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
-- 
View this message in context: http://old.nabble.com/control-order-of-em.remove%28%29-calls-tp29366675p29399787.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top