db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: JDO-61
Date Thu, 09 Jun 2005 23:44:36 GMT
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,T 
HIS.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,T 
HIS.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,T 
HIS.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,T 
HIS.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,T 
HIS.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.InstancesPersistedPriorToIterationReturn 
>>>> ed  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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message