Apache JDO Project - [IMPORTANT] Fetch-depth

Author

[IMPORTANT] Fetch-depth

Craig L Russell

2006-01-13, 8:48 pm

Alexander Bieber

2006-01-16, 5:46 pm

Thanks Craig for taking our arguments into account.
I'll still have a comment concerning the use case Jörg von Frantzuis
submitted. His case is to limit the object-plan depth to a certain level
while using FetchPlan.ALL as fetch-group. This is used for synchronizing
data between datastores generically. In my oppinion we should think of
an additional and optional (defaulting to -1) parameter to detachCopy -
detachDepth - for this case.

Best regards

Alexander Bieber

Craig L Russell wrote:

> Javadogs,
>
> I've spent some time looking at the semantics of fetch-depth and now
> agree with the critics of the change that I proposed back in the
> infamous October 1, 2005 message to the expert group subject: *Re:
> JDO2 §12.7.2: fetch-depth only for "recursive fetch group references"?*.
>
> I now believe it's impractical to use fetch-depth to mean the maximum
> depth of the object graph reachable from the root object(s) field
> because of several messages sent on the subject by Joerg von
> Frantzuis, Alexander Bieber, and Marco Schultz.
>
> Briefly, the argument is that if fetch-depth limits the number
> absolutely, then it's not possible easily to use the fetch-group to
> add another field to a fetch plan simply by adding a fetch-group that
> includes that field. Instead, a new fetch-group that changes the
> fetch-depth must be used. And each new use-case needs to provide a
> different fetch-depth number if another level of fetching is desired.
>
> I believe that the use of fetch-group to determine whether fields
> (navigating relationships) are fetched should be natural, and that we
> should therefore use fetch-depth for its original purpose of limiting
> recursion.
>
> If you disagree with this position, please reply so we can move
> forward and define the use of fetch-depth for recursion (as in the
> original semantics of the attribute).
>
> Thanks,
>
> Craig
>
> 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!
>
>

Jörg von Frantzius

2006-01-16, 5:46 pm

Thank you Alexander, I hadn't been watching!

Alexander Bieber schrieb:
> Thanks Craig for taking our arguments into account.
> I'll still have a comment concerning the use case Jörg von Frantzuis
> submitted. His case is to limit the object-plan depth to a certain
> level while using FetchPlan.ALL as fetch-group. This is used for
> synchronizing data between datastores generically. In my oppinion we
> should think of an additional and optional (defaulting to -1)
> parameter to detachCopy - detachDepth - for this case.
If fetch-depth is meant to limit recursion (or if it would more
accurately be renamed to "recursion-depth", see below), then there would
be no way anymore of determining the fetch-depth absolutely when
detaching. As Alexander said, my usecase depends on that and my code
would break. If anyone is interested to know why synchronizing two
different databases in a generic way depends on that, then I'll be happy
to elaborate further.

I'd be equally happy with a fetchDepth parameter to PM.detachCopy(), as
Alexander proposes.
>
> Best regards
>
> Alexander Bieber
>
>
> Craig L Russell wrote:
>
Two remarks if we want to limit recursion:

1. It shouldn't be called "fetch-depth" but "recursion-depth",
because that's what it is then (it does not determine the actual
number of fetches!)
2. It should be clearly defined what kind of recursion is meant here,
i.e. by class or by object. I remember it being agreed that by
object is the most useful.
[vbcol=seagreen]
>
>

--
________________________________________
__________________
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
_______________________________|________
__________________

Jörg von Frantzius

2006-01-16, 5:46 pm

My fingers typing too fast for my head here, sorry...

Jörg von Frantzius schrieb:
> 2. It should be clearly defined what kind of recursion is meant here,
> i.e. by class or by object. I remember it being agreed that by
> object is the most useful.
I meant to say that *by class* seems to be the most useful here.

--
________________________________________
__________________
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
_______________________________|________
__________________

Craig L Russell

2006-01-16, 5:46 pm

Craig L Russell

2006-01-16, 5:46 pm

Jörg von Frantzius

2006-01-17, 5:45 pm

Hi Craig,

did you get the mail to you personally where I described it? Maybe I
ended up in you spam-filter or something...

Regards,
Jörg

Craig L Russell schrieb:
> Hi
>
> Yes, I'm interested in this use-case in detail. I'm still open to an
> absolute fetch-depth if there is a need for it.
>
> Thanks,
>
> Craig
>
> On Jan 16, 2006, at 8:13 AM, Jörg von Frantzius wrote:
>
>
> 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!
>
>

--
________________________________________
__________________
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
_______________________________|________
__________________

Craig L Russell

2006-01-27, 8:47 pm

Matthew T. Adams

2006-01-27, 8:47 pm

See comments inline...

-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
Sent: Wednesday, January 25, 2006 11:54 AM
Cc: JDO Expert Group; Apache JDO project
Subject: Re: [IMPORTANT] Fetch-depth

Javadogs,

Here's what I'm proposing, in summary.

1. Add a property to FetchPlan: get/setMaxFetchDepth. This property limits
the depth of the fetched instance graph counting from the root of the
instances. The roots are defined for queries as the results of the query.
The roots of retrieve and detachCopy are the parameter instances. The
default is 1, meaning fetch one level of objects reachable from the roots. A
value of 0 has no meaning, because if a relationship field is in the fetch
group, it will be fetched.

Don't forget that the roots are also the parameter instances of refresh, in
addition to retrieve and detachCopy. Setting a value of 0 for maxFetchDepth
should throw JDOUserException.

2. Add a property to FetchPlan: get/setDetachRoots. The roots for
DetachAllOnCommit are all the instances in the DetachRoots on FetchPlan. The
default is all instances in the cache. Or it could be all instances
retrieved by queries, explicitly made persistent, or explicitly retrieved.

I'd advocate a slight change in the name to get/setDetachmentRoots. It
would be nice to be able to have a convenient method overload for
setDetachmentRoots(Class pcClass) and/or getDetachmentRoots(Class[]
pcClasses) so that users could easily specify all instances of a specific
class or set of classes.

3. In order to avoid confusion, remove fetch-depth attribute for the field
element and replace it with recursion-depth attribute. This has two effects:
it requires users to change their metadata and think about what the
fetch-depth was used for; and it better reflects the purpose of the
attribute to limit recursion. The meaning of recursion-depth is the maximum
number of links to follow from the target instance of this field in case the
same class is encountered again.

How does inheritance affect this? It seems to me that this should also
apply when the the target field's class is the same as or a subclass of the
field's class.

4. In case of multiple definitions of the same field recursion-depth, the
largest number for the same field will be used. That is, if the same field
is declared in multiple fetch groups, a simple MAX of all the values is
used.

I'll write up a number of examples and send them tomorrow.

Comments?

Craig

On Jan 13, 2006, at 3:10 PM, Craig L Russell wrote:

Javadogs,

I've spent some time looking at the semantics of fetch-depth and now agree
with the critics of the change that I proposed back in the infamous October
1, 2005 message to the expert group subject: Re: JDO2 §12.7.2: fetch-depth
only for "recursive fetch group references"?.

I now believe it's impractical to use fetch-depth to mean the maximum depth
of the object graph reachable from the root object(s) field because of
several messages sent on the subject by Joerg von Frantzuis, Alexander
Bieber, and Marco Schultz.

Briefly, the argument is that if fetch-depth limits the number absolutely,
then it's not possible easily to use the fetch-group to add another field to
a fetch plan simply by adding a fetch-group that includes that field.
Instead, a new fetch-group that changes the fetch-depth must be used. And
each new use-case needs to provide a different fetch-depth number if another
level of fetching is desired.

I believe that the use of fetch-group to determine whether fields
(navigating relationships) are fetched should be natural, and that we should
therefore use fetch-depth for its original purpose of limiting recursion.

If you disagree with this position, please reply so we can move forward and
define the use of fetch-depth for recursion (as in the original semantics of
the attribute).

Thanks,

Craig

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!

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!

Jörg von Frantzius

2006-01-27, 8:47 pm

Hi all,

please see my comments below.

Craig L Russell schrieb:
> Javadogs,
>
> Here's what I'm proposing, in summary.
>
> 1. Add a property to FetchPlan: get/setMaxFetchDepth. This property
> limits the depth of the fetched instance graph counting from the root
> of the instances. The roots are defined for queries as the results of
> the query. The roots of retrieve and detachCopy are the parameter
> instances. The default is 1, meaning fetch one level of objects
> reachable from the roots. A value of 0 has no meaning, because if a
> relationship field is in the fetch group, it will be fetched.
Would a value of -1 then mean "fetch indefinitely"? I'd somehow find
that intuitive.
>
> 2. Add a property to FetchPlan: get/setDetachRoots. The roots for
> DetachAllOnCommit are all the instances in the DetachRoots on
> FetchPlan. The default is all instances in the cache. Or it could be
> all instances retrieved by queries, explicitly made persistent, or
> explicitly retrieved.
>
> 3. In order to avoid confusion, remove fetch-depth attribute for the
> field element and replace it with recursion-depth attribute. This has
> two effects: it requires users to change their metadata and think
> about what the fetch-depth was used for; and it better reflects the
> purpose of the attribute to limit recursion. The meaning of
> recursion-depth is the maximum number of links to follow from the
> target instance of this field in case the same class is encountered
> again.
Shouldn't it simply be the number of times the given class can be
traversed while fetching? If we specify a recursion depth, then the
resulting number of actual fetches (links followed) depends on the
length of any class cycles encountered in the object graph. So we're not
directly giving a number of fetches here.
>
> 4. In case of multiple definitions of the same field recursion-depth,
> the largest number for the same field will be used. That is, if the
> same field is declared in multiple fetch groups, a simple MAX of all
> the values is used.
>
> I'll write up a number of examples and send them tomorrow.
>
> Comments?
>
> Craig
>
> On Jan 13, 2006, at 3:10 PM, Craig L Russell wrote:
>
>
> 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!
>
>

--
________________________________________
__________________
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
_______________________________|________
__________________

Craig L Russell

2006-01-27, 8:47 pm