[
https://issues.apache.org/jira/browse/OPENJPA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Solodovnik resolved OPENJPA-3010.
---------------------------------------
Fix Version/s: 4.2.0
Assignee: Richard Zowalla
Resolution: Fixed
> Bulk delete and map key tests assert Derby-shaped SQL and fail on MySQL
> -----------------------------------------------------------------------
>
> Key: OPENJPA-3010
> URL: https://issues.apache.org/jira/browse/OPENJPA-3010
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> Six tests added by the OPENJPA-2990 / OPENJPA-2994 / OPENJPA-2965 work assert
> SQL shapes that only hold on Derby and H2, so a full MySQL run fails.
> Reported by Maxim Solodovnik on the dev list while running the MySQL suite.
> Reproduced on master (b4bfa57f0) against mysql:8.0 via -Dtest-mysql-docker, 6
> failures:
> TestBulkDeleteJoinTable.testBulkDeleteWithoutCriteriaEmptiesOwnedTables
> TestBulkDeleteSubclassJoinTable.testBulkDeleteThroughBaseClass
> TestBulkDeleteCompositeId.testCompositeKeyCandidateWithoutCriteria
>
> TestBulkDeleteDependentFields.testUnfilteredDeleteCleansOwnedTablesOfDependentFields
> TestBiDirectionalJoinTable.testBulkDelete
> TestContainerSpecCompatibilityOptions.testLegacyDefaultMapKeyColumnName
> Two distinct causes.
> 1. The criteria-less bulk delete renders differently on MySQL. The assertions
> expect "DELETE FROM <table>" with an optional alias appended, i.e. the
> regular expression "DELETE FROM .*BULK_OWNER( t[0-9]+)?", while MySQL emits
> the alias before the FROM:
> DELETE t0 FROM BULK_OWNER t0
> Derby and H2 emit "DELETE FROM BULK_OWNER" and "DELETE FROM BULK_OWNER t0"
> respectively, which is what the patterns were written against. Five of the
> six failures are this.
> 2. The legacy map key column name is dictionary specific.
> testLegacyDefaultMapKeyColumnName asserts the generated DDL contains KEY0,
> which is what Derby produces because KEY is in its invalid-column-word set
> and OpenJPA renames it. MySQL instead delimits the reserved word, so the DDL
> contains a delimited lower case key:
> CREATE TABLE Uni_Map_KeyCol_attrs (UniMapKeyCol_ID BIGINT, `key`
> VARCHAR(255), `value` VARCHAR(255)) ENGINE = innodb
> Both are test defects, not product defects: the product behaviour is correct
> on each database, the assertions are written for one dialect. Fix the
> assertions to be dictionary agnostic (tolerate the MySQL delete form, and
> derive the expected column name from the dictionary rather than hard coding
> KEY0).
> Note why CI did not catch it: the GitHub Actions matrix runs only the
> test-derby and test-h2 profiles, so no MySQL, MariaDB or PostgreSQL run
> happens on a pull request. Any assertion on emitted SQL therefore needs to be
> checked against the other dictionaries by hand before merging, or the matrix
> needs extending.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
