[
https://issues.apache.org/jira/browse/OPENJPA-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123706#comment-18123706
]
ASF subversion and git services commented on OPENJPA-2965:
----------------------------------------------------------
Commit 85132b22d83a9e0728b2d1b7bc17add084db9124 in openjpa's branch
refs/heads/master from Paulo Cristovão de Araújo Silva Filho
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=85132b22d ]
Merge pull request #199 from apache/OPENJPA-2965
[OPENJPA-2965] Pin the bulk delete of a candidate with cascade delete fields
> 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)
