Hi Tom,
I looked into the issues running entity-persistence-tests on derby. The
attached jar changes 4 files in entity-persistence-tests and one in
entity-persistence and with these changes all the tests pass on oracle
and on derby. You find some more details about the changes below.
> Hi,
>
> running the tests from entity-persistence-tests on derby results in 9
> failures and 3 errors. You find the testsresults file attached.
>
> Failures
> - 8 failures are issues with queries using date, time, or timestamp values.
Class JUnitEJBQLDateTimeTestSuite in the ejbqltesting package runs a
number of test queries comparing a timestamp field with a timestamp
parameter. The calendar object used to specify the actual parameter
value sets the milliseconds to 0 where the Java code creating the test
data explicitly sets a non-0 milliseconds value. After changing the
milliseconds to the non-0 value the tests succeed on derby.
But then these test failed on Oracle. The reason is that the
OraclePlatform maps the Java types java.sql.Time and java.sql.Timestamp
to a SQL DATE which does not store milliseconds in oracle. I changed the
OraclePlatform to maps these types to a SQL TIMESTAMP.
> - testReadJuniorScientist fails reading a persistence instance.
Test testReadJuniorScientist in AdvancedCompositePKJunitTest fails
finding a JuniorScientist instance by primary key. Class JuniorScientist
has a primary key field annotated with @GeneratedValue using the
SEQUENCE strategy. The test code creates a JuniorScientist instance
calls EM.persist and then retrieves the primary key value to be used in
a EM.find call later in the code. It looks like with derby this primary
key field gets its value at commit time and not at EM.persist time. So
the stored primary key value is not valid and EM.find fails.
I changed the setup code and get the primary key value after commit.
>
> Errors:
> - Test testBindParametersWithPostitional results in a SqlException
> because the generated SQL uses JPQL input parameter syntax, so '?1'
> instead of '?': ... AND t1.BUDGET > ?1 ...
This is in test method testBindParametersWithPostitional in class
SQLResultSetMappingTestSuite. I replaced the ?1 by ? in the SQL statement.
> - Test testPessimisticLocking results in a SqlException: FOR UPDATE is
> not permitted in this type of statement.
This is in test method testPessimisticLocking in class
SQLResultSetMappingTestSuite. The test runs a SQL SELECT statement
having FOR UPDATE clause testing the SqlResultSetMapping feature. The
query returns a LargeProject instance which is mapped to two tables: the
superclass table and another table for the declared fields. So the SQL
includes two tables in FROM clause. This SQL fails on derby, because
derby does not support a FOR UPDATE query having more than one table in
the FROM clause.
I having two tables is not important for this test, so I changed it to
query for a SmallProject which is completely mapped to the superclass table.
> - Test testTrimWithoutTrimChar results in a SqlException: 'TRIM' is not
> recognized as a function or procedure.
Class ExpressionJUnitTestSuite has a number of test methods creating
TopLink queries that explicitly use the trim() method provided by
Expression. Since trim is not supported on derby, you have to use the
methods ltrim and rtrim. All the test methods using trim check whether
the platform is derby and if so the test is not executed. Just method
testTrimWithTrimChar did not include the platform test. I added this.
Regards Michael
>
> Regards Michael