[
https://issues.apache.org/jira/browse/OPENJPA-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123705#comment-18123705
]
ASF subversion and git services commented on OPENJPA-2990:
----------------------------------------------------------
Commit db0926b2237e331d146a9632cc0f8a65898c22f1 in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=db0926b22 ]
[OPENJPA-2965] Pin the bulk delete of a candidate with cascade delete fields
Removing the cascade guard from the JDBC bulk delete strategy no longer
leaves the rows of the join tables and element collection tables behind: the
delete cleans up the tables the candidate owns itself. The guard rejected a
field whose own value had a cascade delete, which is what OpenJPA's
@Dependent and a to-one cascade=REMOVE set; a collection declares its cascade
on the element value, which the guard never read, so only a single-valued
relation ever forced the delete onto the in-memory path, where the owned
tables were cleaned up as a side effect of removing every instance. Nothing
covered that shape, so a regression could pass unnoticed.
The new test deletes such a candidate - one dependent and one cascade=REMOVE
direct relation next to a dependent join table collection, a dependent
bi-directional one-to-many and an element collection - and asserts that the
join table and the element collection table are emptied while the related
entity rows survive: the targets of the direct relations, the elements of the
join table collection and the rows of the one-to-many, whose foreign key
lives in a table the candidate does not own. A bulk delete does not cascade
(specification section 4.10), so none of those rows is an owned row.
The migration note described the previous behaviour for an @ElementCollection
the wrong way round. Such a candidate already took the bulk SQL path and its
collection table rows were left behind on the deleted keys; removing them is
a fix (OPENJPA-2990), not a replacement for cascading that was lost.
> Bulk delete no longer cleans join-table rows
> --------------------------------------------
>
> Key: OPENJPA-2990
> URL: https://issues.apache.org/jira/browse/OPENJPA-2990
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683006632
> **(high)** testSingleDelete/testBulkDelete were inverted from "addresses
> deleted" to "addresses remain" citing spec 4.10 - but that clause has said
> bulk delete does not cascade since JPA 1.0, so this is a deliberate break
> with long-standing OpenJPA behavior rather than something new in 3.2. Also
> the `assertSQL("DELETE FROM .*J_PERSON_ADDRESSES .*")` assertions were
> dropped entirely: are the join-table rows still cleaned up, or do we now
> leave dangling rows pointing at deleted pks (FK violation on constrained
> schemas)? Please keep an assertion on the join-table state and consider a
> compatibility option plus release note. Same change in
> TestBulkJPQLAndDataCache.java:122.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
