You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Marco Schulze <Ma...@NightLabs.de> on 2005/12/16 17:28:33 UTC
fetch-depth + recursion-depth
Dear JDO Expert Group,
may we kindly request an extension of the JDO spec: Additionally to
"fetch-depth", there should be a "recursion-depth" declarable per field
within a fetch-group.
I'd like to explain what I mean with a little use-case:
Imagine, we've got the following classes:
class City {
List<Factory> factories;
List<Shop> shops;
}
class Factory {
City city;
List<Car> cars;
}
class Car {
List<Factory> factories;
List<Shop> shops;
}
class Shop {
City city;
List <Car> cars;
}
...and we're using an EJB (or whatever backend-object) with the
following methods:
Factory getFactory(FactoryID id, String[] fetchGroups);
Car getCar(CarID id, String[] fetchGroups);
Shop getShop(ShopID id, String[] fetchGroups);
Now, we first imagine, we have a "recursion-depth" available. This
"recursion-depth" is not counted relative to the absolute root of the
object graph (like the fetch-depth), but only when the same field of the
same class is recursively passed by the detach-process. In order to give
the client the maximal flexibility to get object graphs shaped in
whatever form he wants, we simply need the following fetch-groups:
* City.factories
* City.this
* Factory.city
* Factory.cars
* Factory.this (contains all fields)
* Car.factories
* Car.shops
* Car.this (contains all fields)
* Shop.city
* Shop.cars
* Shop.this (contains all fields)
All of these fetch-groups would be declared with fetch-depth=0 and
recursion-depth=1.
But then, let's assume we have no "recursion-depth" (as it is currently
the case) and only a "fetch-depth", which is counted relative to the
root of the object graph. In order to give the client the same
flexibility, we need many more fetch-groups:
Fetch Group | Fetch-Depth | Possible Object Graphs
-------------------------------|----------------------------------
City.factories_1 | 1 | City => Factory
------------------------------------------------------------------
City.factories_2 | 2 | Shop => City => Factory
| | Factory => City => Factory
------------------------------------------------------------------
City.factories_3 | 3 | Car => Factory => City => Factory
| | Car => Shop => City => Factory
------------------------------------------------------------------
City.shops_1 | 1 | City => Shop
------------------------------------------------------------------
City.shops_2 | 2 | Factory => City => Shop
| | Shop => City => Shop
------------------------------------------------------------------
City.shops_3 | 3 | Car => Factory => City => Shop
| | City => Factory => City => Shop
| | Car => Shop => City => Shop
| | City => Shop => City => Shop
------------------------------------------------------------------
Factory.city_1 | 1 | Factory => City
------------------------------------------------------------------
Factory.city_2 | 2 | City => Factory => City
| | Car => Factory => City
------------------------------------------------------------------
Factory.city_3 | 3 | Shop => City => Factory => City
| | Factory => City => Factory => City
| | Shop => Car => Factory => City
| | Factory => Car => Factory => City
------------------------------------------------------------------
MANY MANY MORE | |
I hope by this - still quite simple - use case, it becomes already
obvious, that the number of necessary fetch-groups explodes. We need for
every possible graph size one more fetch-group per field. This is really
a lot! The alternative would be to only define those fetch-groups that
are currently needed, but then the backend has to be changed whenever
the front-end needs different object graphs - and IMHO this would be bad
design.
I see the following possibilities:
* Add "recursion-depth" to the spec and have the detach-process stop
detaching whenever the first limit (fetch-depth or
recursion-depth) has been reached for a field.
* Make "fetch-depth" to what I named "recursion-depth" as can
already be understood from the current spec. Then it would of
course be necessary to add a maximum fetch-depth to either the
detachCopy method or to the fetch plan.
* Leave it as it is and force either the JDO user to declare many
fetch-groups (which is error-prone and unconvenient) or the JDO
implementation to offer a vendor-extension.
Thank you very much in advance for considering one of the first two
solutions.
Best regards,
Marco Schulze
NightLabs GmbH
Re: fetch-depth + recursion-depth
Posted by Jörg von Frantzius <jo...@artnology.com>.
Marco Schulze wrote:
> Jörg von Frantzius wrote:
>> After having thought about it for a while, I started to doubt whether
>> we really need a "recursion-depth" number here. Can you think of a
>> case where you'd need any value greater than 1 here?
> We have a case in which we need a "recursion-depth" greater than 1:
>
> We use a tree of objects (all of the same class, self-referencing via
> a Collection), where the GUI loads this tree initially with
> recursion-depth=2 in order to immediately show the first level of the
> tree expanded and the second level ready - with already knowing
> whether an expand-icon needs to be visible or not. In other words: we
> load always one level more in the tree than is visible for
Now that's convincing! Sorry for not having thought of this case, and
please forget about that "recurse-class-cycles" flag. I'd absolutely
second a proposal for a "recursion-depth" number; if anyone would ask
me, that is ;)
Regards,
Jörg
--
__________________________________________________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|__________________________
RE: fetch-depth + recursion-depth
Posted by David Jordan <da...@bellsouth.net>.
Allowing multiple levels of a tree structure to be pre-fetched would allow
more efficient traversal of the tree structure than simply iterating one
level at a time. The implementation could use relational vendor specific
features, I know Oracle supports such recursive traversals.
David Jordan
Object Identity, Inc.
-----Original Message-----
From: Marco Schulze [mailto:Marco@NightLabs.de]
Sent: Monday, December 19, 2005 7:23 AM
To: jdo-dev@db.apache.org
Cc: jdo-experts-ext@sun.com
Subject: Re: fetch-depth + recursion-depth
Jörg von Frantzius wrote:
> After having thought about it for a while, I started to doubt whether
> we really need a "recursion-depth" number here. Can you think of a
> case where you'd need any value greater than 1 here?
We have a case in which we need a "recursion-depth" greater than 1:
We use a tree of objects (all of the same class, self-referencing via a
Collection), where the GUI loads this tree initially with
recursion-depth=2 in order to immediately show the first level of the
tree expanded and the second level ready - with already knowing whether
an expand-icon needs to be visible or not. In other words: we load
always one level more in the tree than is visible for avoiding the
expand-icon to be visible even though there are no children.
> So I'd rather call this a boolean flag "recurse-class-cycles".
IMHO, the implementation work for a boolean flag is the same as for a
number, so the flexibility of a count should be preferred.
> I can't see why the spec should be changed for this rather than
> extended. Your requirement for a cycle-detection probably doesn't
> invalidate existing requirements for an absolute fetch-depth.
With "changed" I meant "extended".
Re: fetch-depth + recursion-depth
Posted by Marco Schulze <Ma...@NightLabs.de>.
Jörg von Frantzius wrote:
> After having thought about it for a while, I started to doubt whether
> we really need a "recursion-depth" number here. Can you think of a
> case where you'd need any value greater than 1 here?
We have a case in which we need a "recursion-depth" greater than 1:
We use a tree of objects (all of the same class, self-referencing via a
Collection), where the GUI loads this tree initially with
recursion-depth=2 in order to immediately show the first level of the
tree expanded and the second level ready - with already knowing whether
an expand-icon needs to be visible or not. In other words: we load
always one level more in the tree than is visible for avoiding the
expand-icon to be visible even though there are no children.
> So I'd rather call this a boolean flag "recurse-class-cycles".
IMHO, the implementation work for a boolean flag is the same as for a
number, so the flexibility of a count should be preferred.
> I can't see why the spec should be changed for this rather than
> extended. Your requirement for a cycle-detection probably doesn't
> invalidate existing requirements for an absolute fetch-depth.
With "changed" I meant "extended".
Re: fetch-depth + recursion-depth
Posted by Jörg von Frantzius <jo...@artnology.com>.
First off, IMHO it is absolutely useful to have a feature for
discovering cycles in the object-graph while detaching, and stopping the
detaching there. This is not achievable by simply applying fetch-groups
that define some fetch-depth (at least not in any reasonable generic form),
Marco Schulze wrote:
> Now, we first imagine, we have a "recursion-depth" available. This
> "recursion-depth" is not counted relative to the absolute root of the
> object graph (like the fetch-depth), but only when the same field of the
> same class is recursively passed by the detach-process. In order to give
> the client the maximal flexibility to get object graphs shaped in
> whatever form he wants, we simply need the following fetch-groups:
> [..]
> All of these fetch-groups would be declared with fetch-depth=0 and
> recursion-depth=1.
After having thought about it for a while, I started to doubt whether we
really need a "recursion-depth" number here. Can you think of a case
where you'd need any value greater than 1 here?
Also, I don't think it should really be the same field of the same class
to be reached to count a cycle, but it should rather be just the same
class that is reached. In the example given it's not a problem, but
there are other thinkable object models where you'd probably fetch too
much if you don't stop in the same class being reached again.
So I'd rather call this a boolean flag "recurse-class-cycles".
> * Make "fetch-depth" to what I named "recursion-depth" as can
> already be understood from the current spec.
Craig had clarified this possible misunderstanding in his mail 'Re: JDO2
§12.7.2: fetch-depth only for "recursive fetch group references"?'. It's
probably going to have a different wording in the next release of the
spec to prevent "fetch-depth" from being understood as some kind of
cycle-detection.
> Then it would of
> course be necessary to add a maximum fetch-depth to either the
> detachCopy method or to the fetch plan.
I can't see why the spec should be changed for this rather than
extended. Your requirement for a cycle-detection probably doesn't
invalidate existing requirements for an absolute fetch-depth.
--
__________________________________________________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|__________________________