Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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







Back to the top