Hi Michael,
The changes look good.
Thanks for fixing these tests,
Tom
Michael Bouschen wrote:
>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
>>
>>
>
>
>
>