Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 82127 invoked from network); 26 Mar 2008 13:52:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Mar 2008 13:52:56 -0000 Received: (qmail 48911 invoked by uid 500); 26 Mar 2008 13:52:53 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 48891 invoked by uid 500); 26 Mar 2008 13:52:53 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 48878 invoked by uid 99); 26 Mar 2008 13:52:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Mar 2008 06:52:53 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates 62.192.10.254 as permitted sender) Received: from [62.192.10.254] (HELO goobak01.day.com) (62.192.10.254) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Mar 2008 13:52:12 +0000 Received: by goobak01.day.com (Postfix, from userid 1212) id 219875087A; Wed, 26 Mar 2008 14:41:47 +0100 (CET) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by goobak01.day.com (Postfix) with ESMTP id 7938A50860 for ; Wed, 26 Mar 2008 14:41:46 +0100 (CET) Received: by wa-out-1112.google.com with SMTP id m38so4417296waf.5 for ; Wed, 26 Mar 2008 06:52:02 -0700 (PDT) Received: by 10.114.150.1 with SMTP id x1mr15484280wad.109.1206539522628; Wed, 26 Mar 2008 06:52:02 -0700 (PDT) Received: from ?192.168.0.105? ( [88.73.117.234]) by mx.google.com with ESMTPS id d24sm1485471nfh.25.2008.03.26.06.51.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Mar 2008 06:51:59 -0700 (PDT) Message-Id: To: dev@jackrabbit.apache.org In-Reply-To: <000801c88f05$1e6827d0$6501a8c0@MeBigFatGuy> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Path Constrained queries X-Priority: 3 Date: Wed, 26 Mar 2008 14:51:51 +0100 References: <000801c88f05$1e6827d0$6501a8c0@MeBigFatGuy> X-Mailer: Apple Mail (2.919.2) From: Alexander Klimetschek X-Virus-Checked: Checked by ClamAV on apache.org The normal solution would be - as you already noted - to start the xpath query with baseNode.getPath(). You are right that resolving the parent path is not needed in the overall use case "search below a given node", but it shouldn't be a performance killer, since the path to the root normally consists of only a handful nodes. Or do you see a performance issue in your environment? Regards, Alex Am 26.03.2008 um 06:49 schrieb Dave Brosius: > I am interested in doing descendant based patch constrained queries. > > > I read section "6.6.3.4 Path Constraint", and infer that in order to > specify path constraints, you must know the full path to the node at > which you are constraining. These seems odd to me. Why doesn't jcr > follow the pattern set by xpath, that being the availability of > relative and absolute xpaths (queries). > > > Why doesn't the query object have a > > > query.setContextNode(node), which specifies from which node the > query begins? > > > > How does one determing the absolute path of a node that you have > retreived by uuid? Do we really need to do a recursive getParent > search to the root? Or, do i really need to store the absolute path > of each node in a node property? This seems really painful. I see > the property jcr:path, but this is apparently only a pseudo property > available only from within the query itself. > > > So the question is how do people do a descendent path constraining > query when you want to start the search at any arbitrary node that > is retrieved by UUID? -- Alexander Klimetschek alexander.klimetschek@day.com