From jdo-dev-return-1184-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Thu Sep 01 09:15:09 2005 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 76997 invoked from network); 1 Sep 2005 09:15:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Sep 2005 09:15:09 -0000 Received: (qmail 76331 invoked by uid 500); 1 Sep 2005 09:15:08 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 76318 invoked by uid 99); 1 Sep 2005 09:15:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 02:15:08 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [80.67.18.15] (HELO smtprelay03.ispgateway.de) (80.67.18.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 02:15:22 -0700 Received: (qmail 19112 invoked from network); 1 Sep 2005 09:15:05 -0000 Received: from unknown (HELO [192.168.100.34]) (383542@[195.143.217.178]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Sep 2005 09:15:05 -0000 Message-ID: <4316C698.9090304@artnology.com> Date: Thu, 01 Sep 2005 11:15:04 +0200 From: =?ISO-8859-1?Q?J=F6rg_von_Frantzius?= Organization: artnology GmbH Berlin User-Agent: Mozilla Thunderbird 1.0.2 - [MOOX M3] (Windows/20050328) X-Accept-Language: en-us, de-de, de, en MIME-Version: 1.0 To: jdo-dev@db.apache.org Subject: Re: Interpretation of fetch depth References: <4315ED3F.9030102@artnology.com> <66222AEF-9CA6-496E-82E9-4C414CC11812@Sun.COM> In-Reply-To: <66222AEF-9CA6-496E-82E9-4C414CC11812@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Craig Russell schrieb: > Hi Jörg, > > The fields to be fetched from the instance(s) reachable from this > field are governed by the fetch plan in effect. That is, the fetch > groups in the fetch plan are used to determine the set of fields to be > fetched. So all of the primitive fields in the fetch groups would be > fetched (and none of the relationship fields, as you pointed out). From looking at all occurrences of "fetch-depth" in the PFD spec, I couldn't find anything that elaborates on my next question: Do you agree that it if we have a choice of fetch-depths for the same field, because the current fetch plan includes multiple groups with different fetch-depths for the same field, that we then chose the maximum of these fetch-depths? That also means we have to interpret 0 as infinite (-1 would have somehow been more intuitive here). Or do we take the minimum of all fetch-depths, with 1 being the smallest? That would mean people have to clear out the default fetch group, or any other predefined fetch groups that include the fields in question, in order to get rid of the default fetch-depth of 1 for their fields. > > If you want only the primary key to be fetched, then you should > specify fetch groups in your fetch plan that do not include "default" > and don't include any of the other fields in the reached class. > > Regards, > > Craig > > On Aug 31, 2005, at 10:47 AM, Jörg von Frantzius wrote: > >> Hi, >> >> in the spec, in §12.7.2 it reads >> >> "Recursive fetch group references are controlled by the fetch-depth >> attribute. A fetch-depth of 0 will fetch the whole graph of >> instances reachable from this field. The default is 1, meaning that >> only the instance directly reachable from this field is fetched." >> >> For a fetch-depth of 1, when we fetch such a reachable instance, what >> fields of that instance should be fetched exactly? All I know is we >> must not fetch any of its object fields, as recursion stops here. One >> solution would be to fetch only the primary key, would that be in the >> sense of the specification? It might seem strange, but for my >> application this makes the most sense. >> >> Regards, >> Jörg >> >> -- >> __________________________________________________________ >> 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: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 _______________________________|__________________________