I am in the process of writing a Castor patch, that doesn't use same query
for the child ids. Basically get rid of the join on the dependency table and
use separate queries for the dependency tables.
In org.exolab.castor.jdo.engine.SQLEngine the change seems rather straight
forward.
select * from master table
for all child dependent objects
select id from child_table
end for all
However I am little stumped in org.exolab.castor.jdo.oql.ParseTreeWalker.
The class uses the org.exolab.castor.jdo.engine.SQLEngine.getFinder() to
genereate the select sql for the object. My question is does the query need
the join on the dependency table? Does it need the child ids from the
dependency table?
Steve
----- Original Message -----
From: "Werner Guttmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 01, 2004 5:41 PM
Subject: Re: [castor-dev] JDO object creation performance flaw
>
> Stephen,
>
> I am still in the process of readying a first patch for this feature. In
the meantime, I'd like to bounce the following issue with you and everybody
else
> interested. It looks like the only way to go about a solution for this is
via dynamic proxies. This implies that ...
>
> a) support for 1:1 lazy loading will only be available for people using
JDK 1.3 and up.
> b) I'll need to introduce a new requirement to get this working. For any
class that you want to lazy load as part of a simple 1:1 relation, you'll
need to
> have an interface. I checked with other tools like OJB, as it looks like
they have taken the same approach. Which comes as no surprise as dynamic
> proxies depend on interfaces.
>
> FWIW
> Werner
>
> On Thu, 1 Jul 2004 12:48:31 -0400, Stephen Ince wrote:
>
> >
> >No problem about testing lazy-loading 1:1. This would of course help
loading
> >of large about objects.
> >I will work on a performance patch for top-level objects with large
number
> >of dependent children.
> >----- Original Message -----
> >From: "Werner Guttmann" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Wednesday, June 30, 2004 4:47 AM
> >Subject: Re: [castor-dev] JDO object creation performance flaw
> >
> >
> >>
> >> Well, if that's the case .. ;-), what would you think about helping us
> >with testing new code, whether it's a feature such as support for
> >lazy-loading 1:1
> >> relations or support for the transient attribute at the <sql> level.
Right
> >now, I've got a patch posted for the transient support, and I'd be very
> >interested to
> >> get some hands-on comments.
> >>
> >> Interested ?
> >>
> >> Werner
> >>
> >> On Tue, 29 Jun 2004 21:10:17 +0100, Gregory Block wrote:
> >>
> >> >
> >> >On 29 Jun 2004, at 15:18, Stephen Ince wrote:
> >> >> Steve --> I think it is an issue for 1:m relations and not for 1:1
> >> >> relations.
> >> >
> >> >At this point, anything which can be done to offer the capability to
> >> >fragment and delay queries is good; more importantly, if that partial
> >> >loading then uses the cache, anything with 1:1 mappings where the
other
> >> >half of the 1 in question is shared by many should instantly see an
> >> >improvement.
> >> >
> >> >So thumbs up on that lazy-load of 1:1, it's still good to see. :)
> >> >
> >> >
> >> >
> >> >-----------------------------------------------------------
> >> >If you wish to unsubscribe from this mailing, send mail to
> >> >[EMAIL PROTECTED] with a subject of:
> >> > unsubscribe castor-dev
> >> >
> >>
> >>
> >>
> >> -----------------------------------------------------------
> >> If you wish to unsubscribe from this mailing, send mail to
> >> [EMAIL PROTECTED] with a subject of:
> >> unsubscribe castor-dev
> >>
> >
> >
> >
> >-----------------------------------------------------------
> >If you wish to unsubscribe from this mailing, send mail to
> >[EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
> >
>
>
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
