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

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
"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

----- James Sutherland
 EclipseLink ,
Wiki: EclipseLink , TopLink 
Forums: TopLink , EclipseLink 
Book: Java Persistence 
Blog: Java Persistence
View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top