Performance test-suite for JDO

Created an attachment (id=439)
Unfinished test-suite

Stein, yes you are suffering from 'polymorphism' .. . Just looking at your
mapping file, here's what seems to be the problem:

<field name="children" type="org.castor.perf.AbstractItem"
collection="collection" get-method="getChildren" set-method="addChild">
<sql many-key="parent_id"/>
<bind-xml auto-naming="deriveByClass" node="element" />
</field>

DatingService.close() does not have a filedMolder to ClassMolder-mapping for
AbstractItem when trying to resolve above relation. It only has such mappings
for classes enlisted in mapping.xml through their corresponding <class>
definitions. Can't you enlist AbstractItem as well, and then use the extends
relationship for the remainder ?

As requirements for performance tests are quite a bit different between XML and
JDO I want to seperate developement of both parts. Therefor I want to change
this to be the XML one and create a new JDO one.

Any comments?

Fine by me.

Ralf, Stein's work actually is a test suite for JDO, afair. Having said that,
Stein, can you please have a look at the latest patches I have attached to bug
1881, as they add (partial) support for polymorphism (Database.load() only), and
see whether they enable you to proceeed ?

Werner, If you like this to be the JDO side, why not .

I think we need to do a lot more than Stein did so far.

• readonly / readwrite access
• objects w/o relations and those with different types of relations
• 1:1 / 1:n / n:m relations
• unidirectional / bidirectional relations
• differnent types of mapping polymorph objects (when supported)
• all objects in cache or not in cache
• queries / load / create / delete / updates (short and long transaction)
• lazy and not lazy loading

We can add tests step by step and calculate an overall performance index as well
as indices according to special needs.

I intend to contribute some focusing on readonly queries as I found some
performance problems there.

Gregory, can you add some to show up the improvements of the new cache
implementation.

> I think we need to do a lot more than Stein did so far.
Yoz are definitely right that a lot of tests need to be added, bug please keep
in mind that Stein could not proceed with his work due to missing support for
polymorphism. Which either has been added already or still needs to be added
(in case of OQL queries).

Stein, could you please provide an updated (unified if possible) patch ?

Stein, I am just trying to integrate the patch provided by you with the
polymorphism preview as offered last week. Here's a couple of small questions:

a) Why do you need both parent and parent_id properties in AbstractPerf ?
b) Is this a result of you trying to work-around missing support for polymorphism.
c) If that's not the case, what's the genuine meaning behind these instance
members ?
d) If it is, how should and could out.xml be modified to be in-line with support
for polymorphism.

Oops, forgot to mention that I modified all occurences to "parent_id" in the
mapping file with a filed mapping as folows:

<field name="parent" type="org.castor.perf.AbstractItem">
<sql name="parent_id" />
</field>

I'll see what I can do about the performance tests.

I'm not sure we should use the "current" patch, but rather start from scratch.

Is it an idea to base a performance test-suite on JUnit since they too should be
independent of one another?

Whatever you prefer ... . Re: JUnit, why not ?

What about using an existing framework?
http://opensourcetesting.org/performance.php

Test 1:n relations

Finished measurements and added TestAll suite

Stein, if you like to continue your original aproache I suggest to open a new issue for this work.