Re: [eclipselink-users] EntitEntityManager.remove: Why does it care abou

[James Sutherland <jamesssss@xxxxxxxxx>]

It is not just recursive relationships, but any constraints between multiple
objects that are being deleted.  A simple case is just A and B, A has a
foreign key to B, you delete both.  Depending on the order that they get
deleted, you may need to update A and set its foreign key to null first. 
Now EclipseLink generally handles ordering deletes based on known
constraints based on your mappings, but just because you have a constraint
in your database doesn't mean you have to map it, so EclipseLink may not
know about all constraints.  An update is also required for bi-directional
constrained relationships or cycles, again in general EclipseLink handles
resolving these itself if everything is mapped correctly, but some cases may
require the application to have more control.  There is also the simple case
that you have a delete trigger or constraint that requires some other
updates before the deletion.

But I agree an option to ignore updates for deleted objects would be useful. 
Please log an bug for this.  There is the performDeletesFirst option, but
something separate from this and easier to configure would be desirable.



Francisco Peredo wrote:
> 
> 
> James Sutherland wrote:
>> 
>> The update occurs because in many cases an object must be updated before
>> being deleted, such as for constraints between objects.  
>> 
>> 
>> 
>>> AFAIK, that is only needed for Parent OneToMany Children relationships,
>>> and in that case, you would update the child  object to make it possible
>>> to delete the parent  object, but in this case, I am trying to delete
>>> the same object I updated, the only moment I think this would be needed
>>> is for a recursive relationship where an object is configured as a
>>> parent of itself... all other cases (IMO) could be optimized to avoid
>>> the update... am I wrong?
>>> 
>> 
>> If you do not want the object updated, the best solution is to not modify
>> it.  You could potentially also refresh or detach (unregister and
>> reregister) the object before calling remove to clear any changes made to
>> it.  There is also an EclipseLink option shouldPerformDeletesFirst that
>> can avoid this, but in general, do not update an object that you do not
>> want updated.
>> 
>> 
>> 
>>> 
>>> Is shouldPerformDeletesFirst  smart enough to know that it will fail for
>>> recursive relationship and fall back to the update then delete behavior
>>> on those cases?
>>> 
>>> 
>> 
>> 
>> 
> 
> 


-----
---
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://www.nabble.com/EntitEntityManager.remove%3A-Why-does-it-care-about-nullable%3Dfalse--tp22942681p22972816.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.