Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Thu, 09 Jun 2005 15:38:59 -0700
From: Michelle Caisse <Michelle.Caisse@Sun.COM>
Subject: Re: JDO-61
In-reply-to: <E372059C-03AD-4E4B-86A1-28B17CEB99D9@Sun.COM>
To: jdo-dev@db.apache.org
Message-id: <42A8C503.5060401@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2)
 Gecko/20040803
References: <AE35ED93-EC34-41DA-BC07-E3E083A789D5@Sun.COM>
 <200506091050.47817.andy@jpox.org> <42A86B9F.9050808@sun.com>
 <200506091825.10242.andy@jpox.org> <42A88C8C.1040709@sun.com>
 <E372059C-03AD-4E4B-86A1-28B17CEB99D9@Sun.COM>

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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>