Hi Tom,
> Hi Michael,
>
> The changes look good.
Thanks! I checked in the changes.
Regards Michael
>
> 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
>>>
>>
>>
>>
>>