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!
