Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <40815D3C.90802@apache.org>
References: <44F4042C-8FA3-11D8-9D39-000A95782782@forthillcompany.com>
 <40815D3C.90802@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <057045EA-90C4-11D8-8E5B-000A95782782@forthillcompany.com>
Content-Transfer-Encoding: 7bit
From: Brian McCallister <mccallister@forthillcompany.com>
Subject: Re: Reference Fetching and Joins in 1.1
Date: Sat, 17 Apr 2004 19:07:38 -0400
To: "OJB Developers List" <ojb-dev@db.apache.org>

I like it!

-Brian

On Apr 17, 2004, at 12:37 PM, Armin Waibel wrote:

> Hi Brian,
>
> Brian McCallister wrote:
>> A couple thoughts on the JDBC access and collection fetching/proxying 
>> going forward:
>> First is the ability to programmatically define auto-retrieves via 
>> something like:
>> QueryByCriteria query = QueryFactory.newQuery(Foo.class, new 
>> Criteria());
>> query.prefetch("foo.bar, foo.bar.waffle, foo.eggs");
>
> +1 This looks very smart to me.
>
>> This would specify to retrieve the bar collection on foo, the waffle 
>> collection on each instance in bar, and the eggs collection on foo, 
>> regardless of what the mapping metadata says.
>
> I'm currently try to implement a prototype of a feature discussed with 
> Robert S. Sfeir some weeks ago. This will allow to dynamically change 
> the metadata reference setting at runtime. If we have such an feature 
> it will be no problem to implement your suggestion.
>
> It will work like this:
>
> // get the RuntimeBinder instance
> RuntimeRegistry rdr = (RuntimeRegistry) 
> broker.serviceBrokerHelper().runtimeBinder();
> // create new RuntimeDescriptor instance
> RuntimeDescriptor rd = rdr.newRuntimeDescriptor();
> // set changes for the reference
> rd.setAutoRetrieve(true);
> // bind descriptor and substitute the declared behaviour
> rdr.bindRuntimeDescriptor(rd, Foo.class, "bar");
> ...
> ...
> rdr.unbindAll(); // or the PB.close() call
> // unbind all RuntimeDescriptor
>
> So it will be no problem to implement your suggestions using this new 
> feature ;-)
>
> What do you think?
>
> The only problem is the cache. The user has take care of the cached 
> objects, because the cache contains now objects based on the runtime 
> reference settings (e.g. without loaded references). So if default is 
> auto-retrieve 'true' and you set 'false' the cache will contain 
> objects without loaded references. In that case user should use the 
> 'refresh' attribute for all references.
>
> regards,
> Armin
>
>> Second, and Jakob shot me down on this once (but I'm going to try 
>> again anyway), is retrieving referenced collections via a join:
>> foo.bar can be done via:
>> select foo.id, foo.prop, bar.id, bar.fooId, bar.prop from foo left 
>> outer join bar on foo.id = bar.fooId;
>> as well as the current:
>> select foo.id, foo.prop from foo;
>> select bar.id, bar.prop, bar.fooId from bar where bar.fooId = ?;
>> It gets entertaining to construct objects from the results, but the 
>> ability to fetch via the join is usually a benefit over multiple 
>> queries -- when the database supports the left outer join. The 
>> queries also get entertaining when you have collections on bar which 
>> should also be in the same join.
>> The behavior of how to retrieve a referenced collection (join vs 
>> separate select) should be in metadata, and joins would need to be 
>> quietly converted to multiple selects on platforms where outer joins 
>> are not supported.
>> Thoughts, opinions?
>> -Brian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org