Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43A69E5D.9040009@artnology.com>
Date: Mon, 19 Dec 2005 12:49:49 +0100
From: =?UTF-8?B?SsO2cmcgdm9uIEZyYW50eml1cw==?=
 <joerg.von.frantzius@artnology.com>
Organization: artnology GmbH Berlin
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
CC: jdo-experts-ext@Sun.COM
Subject: Re: fetch-depth + recursion-depth
References: <43A2EB31.5040204@NightLabs.de>
In-Reply-To: <43A2EB31.5040204@NightLabs.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
_______________________________|__________________________