[
https://issues.apache.org/jira/browse/OPENJPA-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125120#comment-18125120
]
ASF subversion and git services commented on OPENJPA-3009:
----------------------------------------------------------
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.
> JPQL LIKE with an escaped wildcard matches only on Derby
> --------------------------------------------------------
>
> Key: OPENJPA-3009
> URL: https://issues.apache.org/jira/browse/OPENJPA-3009
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Reporter: Richard Zowalla
> Priority: Major
>
> TestEJBQLCondExpression.testLikeExpr fails on every database except Derby,
> which means OpenJPA's handling of the JPQL LIKE escape is Derby specific. It
> is not caught by CI because only Derby and H2 are run there, and the H2
> failure has been treated as flakiness.
> Measured with the JPQL test package (193 tests) on each profile, all on
> unmodified master:
> Derby pass
> H2 testLikeExpr fails, expected:<1> but was:<0>
> PostgreSQL 11 testLikeExpr fails, expected:<1> but was:<0>
> MariaDB 11.8 testLikeExpr fails, expected:<1> but was:<0>
> MySQL 8.0 testLikeExpr fails, expected:<1> but was:<0>
> The failing assertion is the one using a backslash escape in the pattern,
> i.e. the 'tes\%' case in
> openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/jpql/expressions/TestEJBQLCondExpression.java
> (testLikeExpr). The query returns no row where one is expected, so the
> pattern is not matching the literal percent sign.
> Worth checking: whether the generated SQL emits an ESCAPE clause at all,
> whether the escape character is passed through or doubled, and how each
> dictionary treats a backslash in a string literal (MySQL and MariaDB treat
> backslash as an escape character inside string literals by default,
> PostgreSQL does not with standard_conforming_strings on, Derby does not at
> all). DBDictionary.searchStringEscape and the LIKE handling in the expression
> tree are the places to start.
> Also worth deciding whether the test itself encodes a Derby specific
> expectation, in which case the test needs splitting per dictionary and the
> behaviour documenting; the point either way is that today the same JPQL query
> gives different results depending on the database.
> PostgreSQL additionally fails TestEJBQLFunction.testExtractHourFromLocalTime
> (expected:<-12> but was:<-11>), also on unmodified master; that one looks
> clock or timezone dependent and may be a separate issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
