[
https://issues.apache.org/jira/browse/OPENJPA-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119743#comment-18119743
]
ASF subversion and git services commented on OPENJPA-2990:
----------------------------------------------------------
Commit a6ff4483ed492114125f32d09c68d6d832ae9854 in openjpa's branch
refs/heads/OPENJPA-2990 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=a6ff4483e ]
[OPENJPA-2990] Remove the rows of the tables owned by bulk deleted entities
A bulk delete does not cascade to related entities, but the rows of the join
tables and element collection tables owned by the deleted entities are not
entities themselves. Since the cascade guard was removed from the JDBC bulk
delete strategy they were left behind, dangling on the primary keys of the
deleted rows.
When the candidate owns such a table, the delete now evaluates the criteria
exactly once into a list of primary keys and deletes by those keys: the owned
tables first, the entity table last. Nothing re-evaluates the criteria against
a database a previous statement has already changed. Candidates with a
composite primary key, or with a join foreign key that is not a single column
referencing that primary key, are executed in memory instead. The
compatibility option CleanupOwnedTablesOnBulkDelete (default true) suppresses
the cleanup.
A delete that carries no criteria at all - no where clause and no
discriminator or subclass condition - matches every candidate row, so every
row of every owned table belongs to a deleted candidate. Such a delete skips
the key select and empties the owned tables outright, which keeps the single
statement delete of a whole table a single statement per table.
The table of a join foreign key is only taken for an owned table if it is
neither a table of the key type nor one of the element type or of any of their
joined superclasses, so an inverse key mapping never turns into a delete of
entity rows. An embedded value has no table of its own - the table of an
embeddable is the table it is embedded into - so the collection table of an
element collection of embeddables is not mistaken for the table of a related
entity.
A join foreign key that carries constant columns discriminates the rows of a
table that is shared by more than one mapping, so the candidates do not own
every row of it: neither the key delete nor the delete without criteria is
applicable and such a candidate is executed in memory.
> 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
> 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)
