Apache JDO Project

Author

JDO-61

Craig Russell

2005-06-08, 8:45 pm

Hi Erik, Andy,

After I fixed the extent iteration outside a transaction, it appears
that JPOX fails test InstancesPersistedPriorToIterationReturn
ed
because it doesn't include a new instance in the iteration.

Could you please look at JDO-61?

Thanks,

Craig

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!

Andy Jefferson

2005-06-09, 7:45 am

> After I fixed the extent iteration outside a transaction, it appears
> that JPOX fails test InstancesPersistedPriorToIterationReturn
ed
> because it doesn't include a new instance in the iteration.
>
> Could you please look at JDO-61?

Hi Craig,

I ran that test on its own - for both datastore identity and application
identity (with latest CVS of JPOX). It passed.

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/applicationidentity.conf
[java] RUN InstancesPersistedPriorToIterationReturn
ed.test
[java] Time: 20.749
[java] OK (1 test)

--
Andy
Java Persistent Objects JDO - JPOX

Michelle Caisse

2005-06-09, 5:45 pm

Hi Andy,

I downloaded the latest JPOX nightly build and I still get the error
reported in JDO-61.

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)?

javax.jdo.PersistenceManagerFactoryClass=org.jpox.PersistenceManagerFactoryImpl
javax.jdo.option.ConnectionDriverName=org.apache.derby.jdbc.EmbeddedDriver
javax.jdo.option.ConnectionURL=jdbc:derby:jdotckdb
javax.jdo.option.ConnectionUserName=tckuser
javax.jdo.option.ConnectionPassword=tckuser
javax.jdo.option.Optimistic=false
javax.jdo.option.RetainValues=false
javax.jdo.option.RestoreValues=false
javax.jdo.option.Mapping=derby

org.jpox.validateTables=false # default = true
org.jpox.validateConstraints=false
org.jpox.autoCreateSchema=false
org.jpox.autoCreateTables=false
org.jpox.autoCreateConstraints=false
org.jpox.autoCreateColumns=false
org.jpox.rdbms.CheckExistTablesOrViews=false
org.jpox.autoStartMechanism=None

-- Michelle

Andy Jefferson wrote:

>
>Hi Craig,
>
>I ran that test on its own - for both datastore identity and application
>identity (with latest CVS of JPOX). It passed.
>
>
>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/applicationidentity.conf
> [java] RUN InstancesPersistedPriorToIterationReturn
ed.test
> [java] Time: 20.749
> [java] OK (1 test)
>
>
>
>

Andy Jefferson

2005-06-09, 5:45 pm

> 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. InstancesPersistedPriorToIterationReturn
ed
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 InstancesPersistedPriorToIterationReturn
ed.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.

--
Andy
Java Persistent Objects JDO - JPOX

Michelle Caisse

2005-06-09, 5:45 pm

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:

>
>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. InstancesPersistedPriorToIterationReturn
ed
>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 InstancesPersistedPriorToIterationReturn
ed.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

2005-06-09, 5:45 pm

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:
>
>
>
>

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!

Michelle Caisse

2005-06-09, 5:45 pm

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:
>
>
> 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

2005-06-09, 8:45 pm

Andy Jefferson

2005-06-10, 5:45 pm

> 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.

Hi Craig,

Well if the JDO impl doesn't know about the PartTimeEmployee class in some
situations of running that test then you could let it know about it :-

pm.getExtent(PartTimeEmployee.class);

--
Andy
Java Persistent Objects JDO - JPOX

Craig Russell

2005-06-10, 5:45 pm

Andy Jefferson

2005-06-10, 5:45 pm

> One reason that we include all the classes in pc/company/package.jdo
> is so that when the package.jdo is read, all the classes are known.
>
> Why doesn't reading the PartTimeEmployee metadata from package.jdo
> tell JPOX that the class exists?

Because JPOX was employing lazy initialisation of MetaData so it would
encounter a file and would parse all classes, but wouldn't initialise the
MetaData for a class until a class of that type was encountered (e.g via a PM
call). This is now changed (next nightly build - 20050611).

I just ran
maven clean database -Dtest=extents. InstancesPersistedPriorToIterationReturn
ed
runtck.single

and got success. I then ran
maven -Dtest=extents. InstancesPersistedPriorToIterationReturn
ed runtck.single

and got success.

--
Andy
Java Persistent Objects JDO - JPOX