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

[Rohit Banga <rohit.banga@xxxxxxxxxx>]

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