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

[Patric Rufflar <patric@xxxxxxxxxxx>]

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<B>  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<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
>
>
>
> _______________________________________________
> 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