Re: JDO-61

[Craig Russell]

Mystery solved, I think. The JPOX log shows that the test that fails doesn't select for part time employees, so it misses one of the rows in the database. The test that succeeds selects for Employee, PartTimeEmployee, and FullTimeEmployee. I don't know the solution, just the symptom. Here's the JPOX log for the Extent iterator from the successful run: SELECT 'org.apache.jdo.tck.pc.company.Employee        ' AS JPOXMETADATA,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM PERSONS THIS WHERE THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.Employee' UNION SELECT 'org.apache.jdo.tck.pc.company.PartTimeEmployee' AS JPOXMETADATA,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM PERSONS THIS WHERE THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.PartTimeEmployee' UNION SELECT 'org.apache.jdo.tck.pc.company.FullTimeEmployee' AS JPOXMETADATA,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM PERSONS THIS WHERE THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.FullTimeEmployee' Here's the JPOX log for the Extent iterator from the failed run: SELECT 'org.apache.jdo.tck.pc.company.Employee        ' AS JPOXMETADATA,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM PERSONS THIS WHERE THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.Employee' UNION SELECT 'org.apache.jdo.tck.pc.company.FullTimeEmployee' AS JPOXMETADATA,THIS.BIRTHDATE,THIS.FIRSTNAME,THIS.LASTNAME,THIS.PERSONID,THIS.HIREDATE,THIS.WEEKLYHOURS FROM PERSONS THIS WHERE THIS.DISCRIMINATOR = 'org.apache.jdo.tck.pc.company.FullTimeEmployee' Craig On Jun 9, 2005, at 3:38 PM, Michelle Caisse wrote: Yes, I would assume that it is a clean-up issue.  In fact, I ran a different test immediately after this one (CompletenessTest) and got a duplicate key error that I don't get when I run the CompletenessTest on its own, so it must be leaving some company model object in the database. -- Michelle Craig Russell wrote: Hi Michelle, I think this is a database init/cleanup issue. The tests are cleverly  written to do a very simple test to see if the database is  initialized, and the test isn't reliable. But the fact that the same  test run twice fails means that either the test is doing something  wrong or the implementation is. Craig On Jun 9, 2005, at 11:38 AM, Michelle Caisse wrote: Yup, it passes on the first run with a clean database, but if you  run the same test a second time it fails.  I've added a comment to  the JIRA. -- Michelle Andy Jefferson wrote: Is there anything in cvs but not in the latest build that would  cause this test to pass? Are you running with the same jdo properties that we do (checked  into test/conf)? What I use is :- Apache JDO : SVN JPOX : CVS I changed a few things in extent handling this morning but nothing  of significance that would affect the creation of the SELECT for  the iterator. What I run is :- maven clean database - Dtest=extents.InstancesPersistedPriorToIterationReturned  runtck.single runtck.single:    [echo] Run TCK test  org.apache.jdo.tck.extents.InstancesPersistedPriorToIterationReturned  on the IUT with configuration /home/andy/work/jdo/trunk/tck20/ test/conf/datastoreidentity.conf    [java] RUN InstancesPersistedPriorToIterationReturned.test    [java] Time: 26.204    [java] OK (1 test) If you wish to investigate the issue you could just look in the  JPOX log. The only issue is the ordering of the INSERT (of the  additional object) and the SELECT (for the Extent). I get the  INSERT before the SELECT when I run as above. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature