[
https://issues.apache.org/jira/browse/OPENJPA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125068#comment-18125068
]
ASF subversion and git services commented on OPENJPA-3010:
----------------------------------------------------------
Commit 5fe588fba88bce2206b9413bec66565b748a7309 in openjpa's branch
refs/heads/OPENJPA-3010 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=5fe588fba ]
[OPENJPA-3010] Assert the bulk delete and map key SQL per dictionary
The tests added with the owned table cleanup and the map key column option
asserted the shape Derby and H2 emit. MySQL and MariaDB render an unqualified
bulk delete as "DELETE t0 FROM T t0" rather than "DELETE FROM T", so the
assertions now accept an alias on either side of the FROM. The legacy map key
column name is spelled differently again by every dictionary - KEY where the
word is legal, KEY0 where it is renamed and a delimited key where it is quoted
instead - so that assertion now compares the generated DDL without delimiters
and without case instead of expecting one spelling.
Reported by Maxim Solodovnik, who runs the MySQL suite by hand; the GitHub
Actions matrix covers only Derby and H2, so no pull request exercises the
other dictionaries.
> 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
> Priority: Major
>
> 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)
