Re: JDO2 §12.7.2: fetch-depth only for "recursive fetch group references"?

[Craig Russell]

Hi Jörg, The term recursive is a bit misleading for fetch-depth, and I apologize for the confusion. The fetch-depth attribute is intended to avoid accidental loading of the entire database (or at least a large portion of it)  into memory due to inadvertent loading of instances that themselves have fetch groups that load instances that have fetch groups and so forth. I referred to this as recursion simply because of fetched instances having other fetched instances. The examples could be improved to include the cases that I intended to cover.  While self-referencing fields are indeed covered by the fetch-depth, other fields are covered as well. Think of the fetch-depth as the maximum number of joins in the SQL statement used to fetch the object graph in one statement.  On Sep 28, 2005, at 3:29 AM, Jörg von Frantzius wrote: [resending this because I haven't seen it coming back from jdo-dev@db.apache.org] Hi Andy, I'm seeing some problems with this current JPOX approach to fetch-depth, and I hope I can make them understandable. Andy Jefferson schrieb: I read the spec that a self-referencing relationship (meaning the field type is the same class that declares the field) is a good use case for the fetch-depth attribute. But I think the use of fetch-depth is not restricted to self-referencing relationships. Am I wrong here?     I agree. I interpret fetch-depth as being for "recursive references" (as the spec says). This encompasses 1. self-referencing (A->A->A->... ) 2. circular-referencing (e.g A->B->C->A->B->C->.....) With fetch-depth=1, how do you discover the circularity while obeying the fetch-depth? (if the associations are all 1:n, you can't fetch the whole path in one go, you'd need more than one fetch) And by the way, do you mean circularity on class level or on object level (you don't do static analysis of circles in the object model, do you?) Let's take a specific example of the case above. class A { B myB; // default fetch-depth 1 } class B { A myA; // default fetch-depth 1 Set<C> myCs; // fetch-depth 2 } class C { B myB; // default fetch-depth 1 A myA; // fetch-depth 3 } Now, if you query class A, you will get all of the A instances that satisfy the query plus all of the B instances directly referenced by the A instances. You get no C instances because the fetch-depth of A.myB limits the results to the directly reachable B instances. If you query class B, you get  1. all of the B instances that satisfy the query;  2. plus all of the A instances directly reachable from B via the myA field (B->A) STOP 3. plus all of the C instances reachable via the B.myCs field (B->C) continue 4. plus all of the B instances reachable via the C.myB field in the C instances in 3 (B->C->B) STOP 5. plus all of the A instances reachable via the C.myA field in the C instances in 3 (B->C->A) STOP If you query class C, you get 1.All of the C instances that satisfy the query 2. plus all of the B instances directly reachable via the C.myB field in the C instances in 1 (C->B) STOP 3. plus all of the A instances directly reachable via the C.myA field in the C instances in 1 (C->A) continue 4. plus all of the B instances directly reachable via the A.myB field in the A instances in 3 (C->A->B) continue 5. plus all of the A instances directly reachable via the B.myA field in the B instances in 4 (C->A->B->A) STOP 6.  plus all of the C instances directly reachable via the B.myCs field in the B instances in 4 (C->A->B->C) STOP There is no requirement that a single database operation will be used to fetch the data. An iterative datastore access strategy is also spec-compliant. Does this help clarify? I will put an example like this into the specification... Craig This is what JPOX aims to support. The examples in the JDO2 spec are, incidentally, only of the self-referencing type. Apart from the above problem, this approach makes it really hard for the user to predict what gets fetched. Just imagine case 2 without the circle (no C->A): if the user wanted to detach an A object, with the number of C objects reachable being really really huge. How could he avoid detaching that A object without detaching a big number of C objects? In my opinion things would be so much simpler if fetch-depth applied to all kinds of fields, and the control over the size of the fetched object graph would be much better. --  __________________________________________________________ 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 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!

smime.p7s
Description: S/MIME cryptographic signature