[
https://issues.apache.org/jira/browse/OPENJPA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125121#comment-18125121
]
ASF subversion and git services commented on OPENJPA-3010:
----------------------------------------------------------
Commit 398666a74b9acaccefea0e89e2e53bf268778911 in openjpa's branch
refs/heads/OPENJPA-3011 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=398666a74 ]
[OPENJPA-3011] Run the other dictionaries on a schedule
The pull request build covers Derby and H2 only, so a defect that is invisible
on those two reaches master and is found when a committer runs another database
by hand: a JPQL LIKE pattern matched only on Derby for several releases
(OPENJPA-3009) and six tests asserted the SQL shape Derby and H2 emit
(OPENJPA-3010). Run the existing MySQL, MariaDB and PostgreSQL docker profiles
weekly instead, and on demand.
The docker-maven-plugin declarations in those profiles carry configuration but
no executions, so nothing starts a container during an ordinary build; the
servers come from service containers with health checks, with the credentials
the respective profile expects. One job per database, because MySQL and MariaDB
both listen on 3306 and a service container cannot be selected per matrix entry.
> 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)
