[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] control order of em.remove() calls
|
Thank you very much for this information.
In the meantime I implemented the solution with flushing after each em.remove(). Not being such a critical area this is feasible.
I will vote for the bug.
Thank you so much,
Christian
Am 10.08.2010 um 18:35 schrieb James Sutherland:
>
> 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.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
