[
https://issues.apache.org/jira/browse/OPENJPA-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126144#comment-18126144
]
ASF subversion and git services commented on OPENJPA-3009:
----------------------------------------------------------
Commit d1f653b1cd4286c6985ec700b1e2f6cbbf0f09af in openjpa's branch
refs/heads/tck-mysql from Paulo Cristovão de Araújo Silva Filho
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=d1f653b1c ]
Merge pull request #208 from apache/OPENJPA-3009
[OPENJPA-3009] Make a JPQL LIKE without ESCAPE mean the same on every database
> 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
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> 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)
