Repository navigation
[OPENJPA-2965] Pin the bulk delete of a candidate with cascade delete fields - #199
Merged
Merged
Conversation
… 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.
solomax
approved these changes
Oct 6, 2026
cristof
approved these changes
Oct 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The orphaned-row concern behind this issue was fixed by OPENJPA-2990: a bulk
DELETEcleans the tables the candidate owns, so the join table and element collection rows of dependent fields no longer dangle, while related entity rows are left untouched as section 4.10 requires. Nothing covered a candidate with cascade delete fields, so this adds that regression test — one dependent and onecascade=REMOVEdirect relation, a dependent join table collection, a dependent bi-directional one-to-many and an element collection. The migration note described the previous@ElementCollectionbehaviour the wrong way round and is corrected.