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:
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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
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
_______________________________|__________________________
