Can you please try the inverse of Case 1?
Read A and B.
Call em.remove(A), change B. Commit.
On 1/28/2011 4:13 PM, patric@xxxxxxxxxxx wrote:
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<B> 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
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
--
Thanks and Regards
Rohit Banga
Member Technical Staff
Oracle Server Technologies
|