You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/04/16 14:40:40 UTC
Reference Fetching and Joins in 1.1
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");
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.
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
Re: Reference Fetching and Joins in 1.1
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Apr 19, 2004, at 3:08 PM, Jakob Braeuchi wrote:
Umh, that is exactly what it is, doh!
> query.addPrefetchedRelationship("eggs")
I want it added to the join =)
Can I say eggs.bacon ?
On the extents: yes it does make it more complicated. I still think it
is worth trying to figure out how to do.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Reference Fetching and Joins in 1.1
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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");
>
> 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.
we already have query.addPrefetchedRelationship("eggs"). what is the difference
in your proposal ? and why do i have to prefix the relationship with "foo" in
the sample ?
>
>
> Second, and Jakob shot me down on this once (but I'm going to try again
> anyway), is retrieving referenced collections via a join:
you're still alive, looks like i'm a bad gunman ;)
>
> 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.
loading the prefetched relationships using a join may be more efficient if the
join is not too complicated. but what if the related class has extents ?
>
> 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.
this makes it even more complicated.
jakob
>
> 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
Re: Reference Fetching and Joins in 1.1
Posted by Brian McCallister <mc...@forthillcompany.com>.
I would put it in 1.0.1 if it doesn't break any 1.0 API's but leave it
out of 1.0 for now. I would like to see 1.0 remain pretty feature
frozen until we can finally push a release out the door.
The post 1.0 backlog is getting huge though -- particularly cool stuff
coming from you, Armin =(
Umh, as we have PMC representation to vote a release -- let's do that!
Once we tag 1.0 and can cut it, the checkin spree for post 1.0 can
begin.
-Brian
On Apr 17, 2004, at 7:22 PM, Armin Waibel wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Reference Fetching and Joins in 1.1
Posted by Armin Waibel <ar...@apache.org>.
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
Re: Reference Fetching and Joins in 1.1
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Re: Reference Fetching and Joins in 1.1
Posted by Armin Waibel <ar...@apache.org>.
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