Ralf,
The slow down many-object is self-referential but it is referencing the
other object by it's id, so I think think it is only self-referential is the
issue. Here is my complete mapping file.
I am trying to load UserScenario--->WebResource->FormData.
The mapping of the self-referential object. ParentWebResourceId is just a
reference to another WebResource.
<class name="com.opendemand.jdo.WebResource" auto-complete="false"
identity="webResourceId" key-generator="keygen" >
<description>Default mapping for class
com.opendemand.jdo.WebResource</description>
<map-to table="web_resource"/>
<cache-type type="none" />
<field name="webResourceId" type="integer" required="false"
direct="false" transient="false">
<sql name="web_resource_id" type="integer" dirty="ignore" />
</field>
<field name="parentWebResourceId" type="integer" required="false"
direct="false" transient="false" >
<sql name="parent_web_resource_id" dirty="ignore" />
</field>
<field name="userScenario" type="com.opendemand.jdo.UserScenario"
required="true">
<sql name="user_scenario_id" dirty="ignore" required="true" />
</field>
:
:
</class>
Steve
----- Original Message -----
From: "Ralf Joachim" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 01, 2006 5:14 PM
Subject: Re: [castor-user] bug in lazy loading in 1.01m
Hi Stephen,
does slow down of 1:n OQL queries only happen with the hierarchy with
self references or also on simple 1:n relations?
If that's the case I think we should add another performance test for this
situation.
Having said that I'll run the other tests in a minute to compare current
results with 0.9.7 ones.
Ralf
Werner Guttmann schrieb:
Hi Stephen,
can you please create separate bug reports for issues 1) and 2) at
http://jira.codehaus.org/browse/CASTOR ?
With regards to issue 1), let me just tell you that I am currently
looking at a very old issue (CASTOR-475) that indicates that Castor has
problems with self-referential relations (1:M) in the context of object
hierarchies (using the extend relation). As far as I can tell, there's
issues with SQL generation in the context of this scenario.
I'll assign issues as you make them available, but please note that 1.0
M2 will ship without any fixes for those two issues to-be-raised.
Finally, let me just express my gratitude for your patience and your
willingness to work on those issues. Very much appreciated.
Regards
Werner
Stephen Ince wrote:
Werner,
I have resolved my issues with lazy loading and upgrading from castor
.9.5.3 to 1.0m1.
Here are my findings.
1) You can't lazy load a list of dependent objects that are self
referential. I think the main issue is that castor uses a collection
for lazy-loading and the order can't be maintained. You really need to
be able to lazy-load a List. Although I did try using a mapping entry
w/o lazy-loading and I still ran into issues with updating and creating.
Resolution: you have to do all your loading, updating and deleting of
self-referential objects programmatically. You can't use the mapping
file.
2) 1-to-many OQL is dramatically slower from from castor .9.5.3 to1.0m1.
Resolution: use jdbc sql to get all the ids, and then use castor to
load the objects independently.
3) Performance improvement loading,updating, and deleting objects in
Castor 1.0m1. I did have a performance patch for .9.5.3 and it is not
needed any more. I think castor is now using a hash set, to keep track
of identities for a transaction.
4) I was intermittently getting duplicate identity errors but that seems
to be resolved.
I can do a bug report for 1 and 2. Let me know if you thing I need more
details.
Steve
----- Original Message ----- From: "Werner Guttmann"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, February 01, 2006 8:45 AM
Subject: RE: [castor-user] bug in lazy loading in 1.01m
Thanks, Steve.
Werner
-----Original Message-----
From: Stephen Ince [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 01. Februar 2006 14:39
To: [email protected]
Subject: Re: [castor-user] bug in lazy loading in 1.01m
Werner,
Thanx for the reply. No. I am going to try a few things.
I can't really use a sortedset, it doesn't allow for
duplicate entries. I will submit a bug report and a work around.
Steve
----- Original Message -----
From: "Werner Guttmann" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, January 31, 2006 3:49 PM
Subject: Re: [castor-user] bug in lazy loading in 1.01m
Stephen,
does the approach as suggested by Ralf address your issue ?
If not, can
you please provide me with a fully working sample (ideally
following the
bug submission guidelines available at
http://castor.codehaus.org) to
replay your problem ?
Thanks
Werner Guttmann
Ralf Joachim wrote:
Hi Stephen,
Werner recently added collection="sortedset" (included
with 1.0M1). I
don't know how it behaves together with lazy loading but
it should be
the best option for you.
You may want to have a look at release-notes for a short
description on
how to use it.
Regards
Ralf
Castor JDO, committer
Stephen Ince schrieb:
I am getting duplicate entries when I am using lazy loading for a
collection. It only happens when I add all the items to
the arraylist.
What is the best way to model lazy loading when the
collection needs to
be sorted?
1--- N
WebResource ------> FormData.
Here is my implementation and mapping file.
Class WebResource {
:
ArrayList formData = new ArrayList();
public void setFormData(Collection formData) {
this.formData.clear();
if ( formData == null ) return;
this.formData.addAll(formData);
final Iterator iter = this.formData.iterator();
while(iter.hasNext() ) {
FormData f = (FormData) iter.next();
f.setWebResource(this);
}
java.util.Collections.sort(this.formData);
}
<class name="com.opendemand.jdo.WebResource" auto-complete="false"
identity="webResourceId" key-generator="keygen"
depends="com.opendemand.jdo.UserScenario">
<field name="formData" type="com.opendemand.jdo.FormData"
required="false" direct="false" transient="false"
collection="collection" lazy="true">
<sql many-key="web_resource_id" dirty="ignore" />
</field>
</class>
Steve
-------------------------------------------------
If you wish to unsubscribe from this list, please send an
empty message
to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty message
to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty message to
the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty message to
the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
