[
https://issues.apache.org/jira/browse/OPENJPA-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123491#comment-18123491
]
ASF subversion and git services commented on OPENJPA-2965:
----------------------------------------------------------
Commit db0926b2237e331d146a9632cc0f8a65898c22f1 in openjpa's branch
refs/heads/OPENJPA-2965 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 dependent/collection rows
> ------------------------------------------------------
>
> Key: OPENJPA-2965
> URL: https://issues.apache.org/jira/browse/OPENJPA-2965
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683002420
> **(medium)** Removing the `getCascadeDelete() != CASCADE_NONE -> INVALID`
> guard means bulk DELETE no longer falls back to loading instances for
> entities with cascading/dependent fields. JPA 4.10 (no cascade on bulk
> delete) is fine, but this strategy also handled dependent-field cleanup:
> join-table / element-collection rows previously removed via the in-memory
> fallback can now be left orphaned unless the DB has ON DELETE CASCADE. Was
> that trade-off verified for the element-collection case?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
