db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Reference Fetching and Joins in 1.1
Date Sat, 17 Apr 2004 23:22:17 GMT
Brian McCallister wrote:

> I like it!
>

The question is should I check in this stuff?

My test case pass. It only needs a new method in BrokerHelper (if this 
feature will be accepted we should find a better place for 1.1) class 
and some minor internal changes in PBImpl, QueryReferenceBroker and 
ObjectReferenceDescriptor.

regards,
Armin

> -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
> 
> 
> 

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


Mime
View raw message