[
https://issues.apache.org/jira/browse/OPENJPA-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131999#comment-18131999
]
ASF subversion and git services commented on OPENJPA-3024:
----------------------------------------------------------
Commit f77551bd60e6cf358052b065893b057dff3ebf8f in openjpa's branch
refs/heads/OPENJPA-3019 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=f77551bd6 ]
[OPENJPA-3024] Keep orphan removal on a relation that also cascades remove
(#224)
* [OPENJPA-3019] test for orphanRemoval case failing for Apache OpenMeetings
* Removal test is improved
* [OPENJPA-3024] Keep orphan removal on a relation that also cascades remove
Since OPENJPA-2940 the annotation parser applied cascade=REMOVE/ALL after
orphanRemoval, so the immediate cascade replaced the dependent marking and
an element removed from such a collection was no longer deleted. Apply
orphanRemoval last again and remove a dependent value together with its
owner, as the specification requires for orphanRemoval.
---------
Co-authored-by: Maxim Solodovnik <[email protected]>
> An element removed from a collection with orphanRemoval and cascade remove is
> not deleted
> -----------------------------------------------------------------------------------------
>
> Key: OPENJPA-3024
> URL: https://issues.apache.org/jira/browse/OPENJPA-3024
> Project: OpenJPA
> Issue Type: Bug
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> An element removed from a collection with {{orphanRemoval = true}} and
> {{cascade = CascadeType.ALL}} (or {{REMOVE}}) is not deleted. On commit only
> the order column of the remaining elements is updated, no {{DELETE}} is
> issued, and a new persistence context still finds the removed element in the
> collection.
> {code:java}
> @OneToMany(mappedBy = "center", orphanRemoval = true, cascade =
> CascadeType.ALL)
> private List<EntityB> services;
> {code}
> {code:java}
> em.getTransaction().begin();
> EntityA a = em.find(EntityA.class, id); // 3 Bs
> a.getBs().remove(a.getBs().iterator().next());
> em.getTransaction().commit();
> // new EntityManager
> em2.find(EntityA.class, id).getBs().size(); // 3, expected 2
> {code}
> Found by the Apache OpenMeetings tests; Maxim Solodovnik added a test for it
> to the OPENJPA-3019 pull request ({{TestOpenJPA2330.testOrthanRemoval}}).
> This is a regression of OPENJPA-2940 (commit 7eba99b9d), which is not in a
> release yet. {{AnnotationPersistenceMetaDataParser.parseOneToOne()}} and
> {{parseOneToMany()}} now call {{setOrphanRemoval()}} before
> {{setCascades()}}, so on a relation with both, the remove cascade replaces
> the dependent marking and {{StateManagerImpl.removed()}} no longer deletes an
> element taken out of the collection.
> Putting {{setOrphanRemoval()}} last again is not enough: OPENJPA-2940 changed
> the order so that the children of a removed owner are removed at
> {{em.remove(parent)}}, as {{TestEntityLifecycleTCK}} checks. So
> {{SingleFieldManager.delete()}} also has to remove a dependent value right
> away when its owner is removed, as section 2.9 of the specification asks for
> orphan removal, while an element dropped from a collection of a remaining
> owner is still deleted at flush.
> Behaviour change: the children of a removed owner on an orphan removal or
> {{@Dependent}} relation become removed, and get their remove callbacks, at
> {{remove()}} of the owner instead of at flush.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
