Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] re move() and a OneToMany mapping with CascadeType.PERSIST 
Calling clear() on the set should cause it to be removed as you will no
longer have a reference to the removed object.  Do you have a reference from
another object?

I can't see how B could get re-persisted if you clear the reference to it
from A.  Are you sure there is no reference to be?  Perhaps put a
break-point in a prePersist event in B and check what is causing it to be
persisted.



patric-7 wrote:
> 
> I have no problem removing all references to an entity which has to be  
> removed.
> What I am trying to point out is that EclipseLink behaves strangely in  
> a special case:
> 
> It makes a difference for EclipseLink if I remove the reference(s) by  
> setting the OneToMany-IndirectSet to null (this will work) or if I  
> call clear() on the IndirectSet (which won't work in case of the  
> cascade types exactly set to CascadeType.PERSIST, CascadeType.MERGE).
> 
> 
> Zitat von James Sutherland <jamesssss@xxxxxxxxx>:
> 
>>
>> Before you remove and object you must ensure that you remove all
>> references
>> to it.  Otherwise you are corrupting your object model.  Normally you
>> would
>> get a constraint error if you tried to delete something that had
>> references,
>> but it depends on the constraint direction.
>>
>> Before removing B you must remove it from A's collection of Bs (and all
>> other object that reference B).
>>
>> The cascade persist in JPA is required by the JPA spec to re-persist
>> removed
>> objects (odd but true).  But not removing the reference to your removed
>> object is wrong and will corrupt your object model irregardless of the
>> JPA
>> issue, so you need to remove its references.
>>
>> If you removed the cascade persist, the object would not get re-persisted
>> (but you object would still be corrupt).
>>
>> EclipseLink does provide some persistence unit properties that control
>> this
>> behavior,
>> "eclipselink.persistence-context.persist-on-commit"="false" - will avoid
>> the
>> auto persist on commit
>> "eclipselink.persistence-context.commit-without-persist-rules"="true" -
>> may
>> resolve the issue
>>
>>
>> patric-7 wrote:
>>>
>>> Your proposed workaround leads to the expected behavior - the entries
>>> are
>>> now
>>> being removed.
>>>
>>> Should I open a bug report?
>>>
>>> Thank you and best regards,
>>> Patric
>>>
>>> Am 28.01.2011 19:02, schrieb Rohit Banga:
>>>> In case 1, can you try the following:
>>>>
>>>>
>>>> // initially a.getBs() will be a set containing one value
>>>> em.remove(B);
>>>> a.setAttr(somevalue);
>>>> a.setBs(null);
>>>>
>>>> In this case I think B should be removed.
>>>> Can you please try this and post the behavior you observe?
>>>>
>>>> Member Technical Staff
>>>> Oracle India Private Limited
>>>> 91 80 41085685
>>>>
>>>> ----- Original Message -----
>>>> From: patric@xxxxxxxxxxx
>>>> To: eclipselink-users@xxxxxxxxxxx
>>>> Sent: Friday, January 28, 2011 7:28:02 PM GMT +05:30 Chennai, Kolkata,
>>>> Mumbai, New Delhi
>>>> Subject: Re: [eclipselink-users] remove() and a OneToMany mapping with
>>>> CascadeType.PERSIST
>>>>
>>>> I'd like to add some additional information:
>>>>
>>>> When adding the CascadeType.REFRESH to the OneToMany mapping,
>>>> the described "behavior" cannot be seen anymore:
>>>>
>>>>     @OneToMany(mappedBy="gtrAnnTaxStmt_",
>>>>                cascade = { CascadeType.PERSIST, CascadeType.MERGE,
>>>> CascadeType.REFRESH })
>>>>     private Set  bSet_;
>>>>
>>>>
>>>> Best regards,
>>>> Patric
>>>>
>>>> Zitat von patric@xxxxxxxxxxx:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I have a question regarding the importance of a remove() against a
>>>>> cascade persist mapping.
>>>>>
>>>>> Imagine a simple parent-child situation reflecting an 1:N cardinality:
>>>>>
>>>>> Entity class A is the parent, entity class B the child.
>>>>> A defines a OneToMany mapping to B:
>>>>>
>>>>>    @OneToMany(mappedBy="a_",
>>>>>               cascade={CascadeType.PERSIST, CascadeType.MERGE} )
>>>>>    private Set  bSet_;
>>>>>
>>>>>
>>>>> In the following example one A instance references to exactly one B
>>>>> instance.
>>>>> Both are already persisted to the database and will be read after
>>>>> the begin of the transaction.
>>>>>
>>>>> Case #1:
>>>>> When calling em.remove(B) and changing A followed by a commit, some
>>>>> strange behavior can be seen:
>>>>>
>>>>> B will not be removed.
>>>>> It seems that the change to A causes that cascade persist will cause
>>>>> a silent 'undeletion' of B.
>>>>> (which happens during changeset calculation on commit)
>>>>>
>>>>> Case #2:
>>>>> When not changing A everything works expected and B will be removed.
>>>>>
>>>>>
>>>>> My questions:
>>>>>
>>>>> 1. Are both cases intentional behavior?
>>>>> I would expect that the explicit remove() should override the
>>>>> implicit cascade persist in either cases.
>>>>>
>>>>> 2. Is there a a workaround that a remove() will be respect with
>>>>> higher priority(beside removing the cascade on the mapping)?
>>>>>
>>>>> Thank you and best regards,
>>>>> Patric
>>>>>
>>>
>>>
>>
>>
>> -----
>> 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
>> Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
>> Performance
>> --
>> View this message in context:  
>> http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p30827278.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
>>
> 
> 
> 
> 
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> 


-----
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 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p30827819.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

Back to the top