[master] Bug 573094: TRIM function generates incorrect SQL for CriteriaBuilder (Oracle platform fix)

[rfelcman]

This is fix related with changes in #1085 "Bug 573094: TRIM function generates incorrect SQL for CriteriaBuilder" based on bug #1084 "Bug 573094: TRIM function generates incorrect SQL for CriteriaBuilder".
It's cover Oracle DB (OraclePlatform). In Oracle DB LTRIM and RTRIM are simple SQL functions with two arguments see
LTRIM https://docs.oracle.com/database/121/SQLRF/functions108.htm#SQLRF00664
RTRIM https://docs.oracle.com/database/121/SQLRF/functions174.htm#SQLRF06104

Before this fix there were test failures in
CORE: org.eclipse.persistence.testing.tests.expressions.ReadAllExpressionTest.RightTrim
JPA: org.eclipse.persistence.testing.tests.jpa.relationships.ExpressionJUnitTestSuite.testLeftTrimWithTrimChar(ExpressionJUnitTestSuite.java:100)
org.eclipse.persistence.testing.tests.jpa.relationships.ExpressionJUnitTestSuite.testRightTrimWithTrimChar(ExpressionJUnitTestSuite.java:205)

Signed-off-by: Radek Felcman radek.felcman@oracle.com

[lukasj]

LGTM

[dazey3]

@rfelcman @lukasj Thank you so much for finding this. I reviewed the documentation and I realize that I made a big mistake in my original understanding/reading of the various platforms and their definitions for LTRIM/RTRIM. My original testing for #1085 is actually wrong:

if(platform.isMySQL() || platform.isDB2() || platform.isDerby() || platform.isSymfoware()) {
    Assert.assertEquals("SELECT STRVAL1 FROM TRIMENTITY WHERE (STRVAL1 = TRIM(LEADING 'A' FROM 'AAHELLO WORDAAAAA'))", _sql.remove(0));
} else {
    Assert.assertEquals("SELECT STRVAL1 FROM TRIMENTITY WHERE (STRVAL1 = LTRIM('A', 'AAHELLO WORDAAAAA'))", _sql.remove(0));
}

For TRIM(LEADING char FROM string) functions, the order and Assert is correct, but I am incorrect for LTRIM(string, char) functions. The order is described in the documentation:

    LTRIM(char [, set])
    
    LTRIM removes from the left end of char all of the characters contained in set.

I had quickly read that (along with other similar documentation) as the first argument being the character TO BE removed from the set; the inverse.

The original reported issue of using the string argument twice for CriteriaBuilder is still valid and will be fixed by this fix. But inverting the arguments for LTRIM/RTRIM usages was something I saw during testing and also fixed as part of this issue. I will need to undo that in a new PR.