[
https://issues.apache.org/jira/browse/OPENJPA-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Solodovnik resolved OPENJPA-2965.
---------------------------------------
Assignee: Richard Zowalla
Resolution: Fixed
> 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
> Assignee: Richard Zowalla
> 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)
