[
https://issues.apache.org/jira/browse/OPENJPA-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121403#comment-18121403
]
ASF subversion and git services commented on OPENJPA-2990:
----------------------------------------------------------
Commit c380948ca9742155413bf4cdf66abbecd09dbe8d 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=c380948ca ]
[OPENJPA-2990] Adding {} for clarity and try-with-resources
> 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)
