Thanks, Andy, for your suggestion and link.

I agree I may have gone overboard by using extents to store typed
values--will try again with all values as VARCHARs and repost if it
improves things a lot.  My sense, though, is that it wasn't the
polymorphism that was screwing things up as much as the collections.
I really do want each experiment to be able to capture a variable
number of data points, so I think I'm stuck with this.

On the issue of JOINs vs. IN-clauses, I agree with Jay and Jakob that
JOINs might be more efficient than what's actually done, but most of
the delay I'm seeing (20 minutes vs. 10 seconds) is not the JDBC calls
but everything OJB does afterward to hook the bits of the object back
together.

So I'm still wondering if I'm missing an obvious way to speed things
up.  Will get rid of extents first; any other ideas appreciated also.

        -j


-----Original Message-----
From: Andy Malakov [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 30, 2004 5:54 PM
To: OJB Users List
Subject: Re: getCollectionByQuery() hung up in prefetchRelationship()


Hello Jason,

I think you took too generic/fine-grained approach when mapped
subclasses of  Value to separate tables. 
Have you considered storing each value type as VARCHAR?

Nice link on this topic:
http://www.agiledata.org/essays/impedanceMismatch.html

All the Best,
Andy

----- Original Message ----- 
From: "Jason Woodard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 30, 2004 1:36 PM
Subject: getCollectionByQuery() hung up in prefetchRelationship()


> Hi,
> 
> I am trying to use OJB to manage experiment data, and have started
> with a naive approach where each experiment is a nested collection
> eventually ending with variable/value pairs.  Storing data works well,
> and retrieving it using getCollectionByQuery() works eventually, but
> is taking much longer than it should.
> 
> When retrieving an experiment object, OJB invokes BasePrefetcher's
> prefetchRelationship(), which makes a bunch of JDBC calls via
> getCollectionByQuery(), which seems to return all the data OJB needs
> to reconstruct the object.  This takes about 10 seconds for my test
> experiment (1000 runs, 25 observations each).  prefetchRelationship()
> then invokes associateBatched(), and stays there for another 20
> minutes with no further debug output, mainly creating Identity
> objects.
> 
> I'm wondering whether I've set up my schema in a way that's grossly
> inefficient for OJB.  (I've appended part of the repository.xml file
> below.)  I've thought about adding a reference from Value back to
> Level, or using explicit PKs instead of anonymous ones, but haven't
> tried either yet.
> 
> FWIW, I'm using OJB 1.0.rc5 with the PB interface against a MySQL
> database (3.0.9-stable driver).
> 
> many thanks for any ideas,
> 
>      -j
> 
> Jason Woodard
> [EMAIL PROTECTED]
> 
> 
> 
> <!-- Definitions for sim.harness.store.Level -->
> <class-descriptor
>     class="sim.harness.store.Level"
>     table="LEVEL"
>     >
>     <field-descriptor
>         name="id"
>         column="ID"
>         jdbc-type="INTEGER"
>         primarykey="true"
>         autoincrement="true"
>         access="anonymous"
>         />
>     <!-- foreign key for parent collection -->
>     <field-descriptor
>         name="seriesId"
>         column="SERIES"
>         jdbc-type="INTEGER"
>         access="anonymous"
>         />
>     <field-descriptor
>         name="variableId"
>         column="VARIABLE"
>         jdbc-type="INTEGER"
>         access="anonymous"
>         />
>     <reference-descriptor
>         name="variable"
>         class-ref="sim.harness.store.Variable"
>         auto-update="true"
>         auto-delete="true"
>         >
>         <foreignkey field-ref="variableId"/>
>     </reference-descriptor>
>     <field-descriptor
>         name="valueId"
>         column="VALUE"
>         jdbc-type="INTEGER"
>         access="anonymous"
>         />
>     <reference-descriptor
>         name="value"
>         class-ref="sim.harness.store.Value"
>         auto-update="true"
>         auto-delete="true"
>         >
>         <foreignkey field-ref="valueId"/>
>     </reference-descriptor>
> </class-descriptor>
> 
> <!-- Definitions for sim.harness.store.Variable -->
> <class-descriptor
>     class="sim.harness.store.Variable"
>     table="VARIABLE"
>     >
>     <field-descriptor
>         name="id"
>         column="ID"
>         jdbc-type="INTEGER"
>         primarykey="true"
>         autoincrement="true"
>         access="anonymous"
>         />
>     <field-descriptor
>         name="name"
>         column="NAME"
>         jdbc-type="VARCHAR"
>         />
> </class-descriptor>
> 
> <!-- Definitions for sim.harness.store.Value -->
> <class-descriptor
>     class="sim.harness.store.Value"
>     >
>     <extent-class class-ref="sim.harness.store.AbstractValue"/>
> </class-descriptor>
> 
> <!-- Definitions for sim.harness.store.AbstractValue -->
> <class-descriptor
>     class="sim.harness.store.AbstractValue"
>     >
>     <extent-class class-ref="sim.harness.store.IntValue"/>
>     <extent-class class-ref="sim.harness.store.DoubleValue"/>
>     <extent-class class-ref="sim.harness.store.BooleanValue"/>
>     <extent-class class-ref="sim.harness.store.StringValue"/>
> </class-descriptor>
> 
> <!-- Definitions for sim.harness.store.DoubleValue -->
> <class-descriptor
>     class="sim.harness.store.DoubleValue"
>     table="DBL_VALUE"
>     >
>     <field-descriptor
>         name="id"
>         column="ID"
>         jdbc-type="INTEGER"
>         primarykey="true"
>         autoincrement="true"
>         access="anonymous"
>         />
>     <field-descriptor
>         name="value"
>         column="VALUE"
>         jdbc-type="DOUBLE"
>         />
> </class-descriptor>
> 
> <!-- etc. for other Value types -->
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to