Re: [eclipselink-users] remove() and a OneToMany mapping with CascadeTyp

[patric@xxxxxxxxxxx]

The result of the inverse of case 1 has the same outcome:
A will not be removed.

Zitat von Rohit Banga <rohit.banga@xxxxxxxxxx>:

> 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