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 Alexander Bieber <al...@nightlabs.de> on 2005/12/15 18:42:37 UTC
Clarifications on fetch depth
Hi all,
with a new version of JPOX I've noticed a change in the behaviour
concerning fetch-depth. After searching the archieves of this list I
believe to understand now that the intended use of fetch-depth is to
restrict the depth object graph of a field upon detaching.
Nevertheless I see problems with that. Before the depth of the
field-based object-graph could be defined by the fetch-plan that a user
had set upon detaching. The only way of breaking this was by the use of
"self-referencing" fields. Doing so it was possible to load large
amounts of the datastore by simply detaching one object with
"unsuitable" fetch-groups. Using the fetch-depth attribute to limit the
graph depth of a detached field surely solves this problem but also
breaks some functionality.
Imagine a PC A holding a list of PCs B that have members of a third PC
C. Now with the restriction on the depth of all fields when detaching
the list of the A a user would have to define different fetch groups for
A's list defining whether B's C member should be included or not. Before
this could be done by including a fetch group for B's C in the
fetch-plan or not.
In my opinion also introduces some application design issues, as a
developer can not be sure that by defining a fetchgroup including a
field of an object this will be included upon detaching. It is no longer
possible (except with fetch-depth=0) to define "generic" fetch-groups so
the user can combine them to define what he wants to retrieve, rather
the developer has to define fetch-groups for each possible usecase and
might have to change the application-backend for new frontends and
usecases.
In my oppinion it would be better to change the spec back to its
previous version, so that fetch-depth applies only to self-referencing
(=recursive) fields (direct _and_ indirect). A hard limit could be set
on detachCopy with an additional parameter detachDepth that will apply
to the object graph of the top-level object that is detached.
Any comments/replies are appreciated.
Best regards Alexander Bieber
Re: Clarifications on fetch depth
Posted by Jörg von Frantzius <jo...@artnology.com>.
Sorry that was meant to go to Marko only, please excuse German being
used here...
Jörg von Frantzius schrieb:
> Hallo Marko,
>
> von Alexander habe ich vorhin gehört, daß Ihr Detaching ebenfalls zum
> Synchronisieren von Datenbanken benutzt. Das tue ich ebenfalls, und es
> funktioniert prima mit dem aktuellen Stand der Spezifikation und von
> JPOX. Und vor allem funktioniert es, ohne daß mein Code wissen muß,
> welche Klasse ein Objekt hat, und mit ein und dem selben
> Fetch-Group-Namen, mit dem für alle Klassen eine Fetch-Group definiert
> ist.
>
> Bitte erkläre mir mal, wie ich ein beliebiges Objekt mit genau Tiefe 1
> detachen kann (also das Objekt selbst, und alles was von diesem direkt
> erreichbar ist), wenn ich keine Fetch-Depth für *alle* Felder
> definieren kann?
>
> Wir können deswegen gerne mal morgen telefonieren, dann gibt's da
> glaube ich weniger Mißverständnisse. Meine Telefonnummer findest Du
> unten.
>
> Grüße,
> Jörg
>
> Grüße,
> J-rg
>
> Marco Schulze schrieb:
>> Alexander Bieber wrote:
>>
>>> In my oppinion it would be better to change the spec back to its
>>> previous version, so that fetch-depth applies only to
>>> self-referencing (=recursive) fields (direct _and_ indirect). A hard
>>> limit could be set on detachCopy with an additional parameter
>>> detachDepth that will apply to the object graph of the top-level
>>> object that is detached.
>>
>> Hello all!
>>
>> I totally agree that the new behaviour not only makes life more
>> complicated, but implies design problems as well, and that a change
>> back to the old behaviour would be very helpful. But instead of a new
>> parameter for the detachCopy method, I'd like to mention a possible
>> alternative: a getter-setter-pair for the fetchplan:
>>
>> PersistenceManager.getFetchPlan().getMaxFetchDepth();
>> PersistenceManager.getFetchPlan().setMaxFetchDepth(mfd);
>>
>> This maximum fetch-depth should be relative to the root of the object
>> graph, while the fetch-depth declared per field only applies to
>> relative self-referencing - i.e. recursion (= old behaviour).
>>
>> IMHO both, detachCopy derivate or fetchplan property, are adequate.
>> But the new behaviour of fetch-groups is not logical, because the
>> definition of a fetch-group happens per field/class while its effects
>> depend on the use-case. IMHO, parameters that apply to the use-case
>> should be defined runtime (i.e. parameter/getter-setter) while static
>> definitions should be usecase-independent. I hope, you understand
>> what I mean...
>>
>> Any other opinions?
>>
>> Best regards, Marco.
>>
>>
>
>
--
__________________________________________________________
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: Clarifications on fetch depth
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hallo Marko,
von Alexander habe ich vorhin gehört, daß Ihr Detaching ebenfalls zum
Synchronisieren von Datenbanken benutzt. Das tue ich ebenfalls, und es
funktioniert prima mit dem aktuellen Stand der Spezifikation und von
JPOX. Und vor allem funktioniert es, ohne daß mein Code wissen muß,
welche Klasse ein Objekt hat, und mit ein und dem selben
Fetch-Group-Namen, mit dem für alle Klassen eine Fetch-Group definiert ist.
Bitte erkläre mir mal, wie ich ein beliebiges Objekt mit genau Tiefe 1
detachen kann (also das Objekt selbst, und alles was von diesem direkt
erreichbar ist), wenn ich keine Fetch-Depth für *alle* Felder definieren
kann?
Wir können deswegen gerne mal morgen telefonieren, dann gibt's da glaube
ich weniger Mißverständnisse. Meine Telefonnummer findest Du unten.
Grüße,
Jörg
Grüße,
J-rg
Marco Schulze schrieb:
> Alexander Bieber wrote:
>
>> In my oppinion it would be better to change the spec back to its
>> previous version, so that fetch-depth applies only to
>> self-referencing (=recursive) fields (direct _and_ indirect). A hard
>> limit could be set on detachCopy with an additional parameter
>> detachDepth that will apply to the object graph of the top-level
>> object that is detached.
>
> Hello all!
>
> I totally agree that the new behaviour not only makes life more
> complicated, but implies design problems as well, and that a change
> back to the old behaviour would be very helpful. But instead of a new
> parameter for the detachCopy method, I'd like to mention a possible
> alternative: a getter-setter-pair for the fetchplan:
>
> PersistenceManager.getFetchPlan().getMaxFetchDepth();
> PersistenceManager.getFetchPlan().setMaxFetchDepth(mfd);
>
> This maximum fetch-depth should be relative to the root of the object
> graph, while the fetch-depth declared per field only applies to
> relative self-referencing - i.e. recursion (= old behaviour).
>
> IMHO both, detachCopy derivate or fetchplan property, are adequate.
> But the new behaviour of fetch-groups is not logical, because the
> definition of a fetch-group happens per field/class while its effects
> depend on the use-case. IMHO, parameters that apply to the use-case
> should be defined runtime (i.e. parameter/getter-setter) while static
> definitions should be usecase-independent. I hope, you understand what
> I mean...
>
> Any other opinions?
>
> Best regards, Marco.
>
>
--
__________________________________________________________
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: Clarifications on fetch depth
Posted by Marco Schulze <nl...@users.sourceforge.net>.
Alexander Bieber wrote:
> In my oppinion it would be better to change the spec back to its
> previous version, so that fetch-depth applies only to self-referencing
> (=recursive) fields (direct _and_ indirect). A hard limit could be set
> on detachCopy with an additional parameter detachDepth that will apply
> to the object graph of the top-level object that is detached.
Hello all!
I totally agree that the new behaviour not only makes life more
complicated, but implies design problems as well, and that a change back
to the old behaviour would be very helpful. But instead of a new
parameter for the detachCopy method, I'd like to mention a possible
alternative: a getter-setter-pair for the fetchplan:
PersistenceManager.getFetchPlan().getMaxFetchDepth();
PersistenceManager.getFetchPlan().setMaxFetchDepth(mfd);
This maximum fetch-depth should be relative to the root of the object
graph, while the fetch-depth declared per field only applies to relative
self-referencing - i.e. recursion (= old behaviour).
IMHO both, detachCopy derivate or fetchplan property, are adequate. But
the new behaviour of fetch-groups is not logical, because the definition
of a fetch-group happens per field/class while its effects depend on the
use-case. IMHO, parameters that apply to the use-case should be defined
runtime (i.e. parameter/getter-setter) while static definitions should
be usecase-independent. I hope, you understand what I mean...
Any other opinions?
Best regards, Marco.
Re: Clarifications on fetch depth
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Alexander,
Thanks for your comments.
I'm persuaded by your argument that the use of fetch-depth is
inappropriate for the simple purpose of limiting the depth of the
fetch tree when recursion is not an issue.
I'll update the proposed final draft to reflect that the fetch-depth
should be used to limit the recursion of the fetch graph.
Craig
On Dec 15, 2005, at 9:42 AM, Alexander Bieber wrote:
> Hi all,
>
> with a new version of JPOX I've noticed a change in the behaviour
> concerning fetch-depth. After searching the archieves of this list
> I believe to understand now that the intended use of fetch-depth is
> to restrict the depth object graph of a field upon detaching.
> Nevertheless I see problems with that. Before the depth of the
> field-based object-graph could be defined by the fetch-plan that a
> user had set upon detaching. The only way of breaking this was by
> the use of "self-referencing" fields. Doing so it was possible to
> load large amounts of the datastore by simply detaching one object
> with "unsuitable" fetch-groups. Using the fetch-depth attribute to
> limit the graph depth of a detached field surely solves this
> problem but also breaks some functionality.
> Imagine a PC A holding a list of PCs B that have members of a third
> PC C. Now with the restriction on the depth of all fields when
> detaching the list of the A a user would have to define different
> fetch groups for A's list defining whether B's C member should be
> included or not. Before this could be done by including a fetch
> group for B's C in the fetch-plan or not.
> In my opinion also introduces some application design issues, as a
> developer can not be sure that by defining a fetchgroup including a
> field of an object this will be included upon detaching. It is no
> longer possible (except with fetch-depth=0) to define "generic"
> fetch-groups so the user can combine them to define what he wants
> to retrieve, rather the developer has to define fetch-groups for
> each possible usecase and might have to change the application-
> backend for new frontends and usecases.
> In my oppinion it would be better to change the spec back to its
> previous version, so that fetch-depth applies only to self-
> referencing (=recursive) fields (direct _and_ indirect). A hard
> limit could be set on detachCopy with an additional parameter
> detachDepth that will apply to the object graph of the top-level
> object that is detached.
>
> Any comments/replies are appreciated.
>
> Best regards Alexander Bieber
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!