From dev-return-21850-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Feb 10 14:34:12 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 73697 invoked from network); 10 Feb 2009 14:34:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Feb 2009 14:34:12 -0000 Received: (qmail 93531 invoked by uid 500); 10 Feb 2009 14:34:11 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 93500 invoked by uid 500); 10 Feb 2009 14:34:11 -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 93491 invoked by uid 99); 10 Feb 2009 14:34:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Feb 2009 06:34:11 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alessandro.bologna@gmail.com designates 74.125.44.28 as permitted sender) Received: from [74.125.44.28] (HELO yx-out-2324.google.com) (74.125.44.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Feb 2009 14:34:04 +0000 Received: by yx-out-2324.google.com with SMTP id 8so221989yxm.1 for ; Tue, 10 Feb 2009 06:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=bj6y1WIghzlILOfJSuwlhMyhcbM+NTgAxWIymAqxllQ=; b=CSs2n90lf+ZsAG9OJVHl/WFFoubrGRypmKSOhZ1wrN6ZnkcP7SqY+kQOyJ9HG/xZUh 1n6FjeFevkscLW1eyNUw8SWnh+CUiNJdcNNnh5sIxBhBW0Ny1gspdon69cUQLSkAPotk CTdO8l/6jc/Wq0F2dPc2kz0k6wfcRC7u7sXxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BMOEzEiMOKk0aH47L9HCspqtY3BIz4RjUD71D4j1ADHeN3suH0WothZ0e8/vFRN+zq GuYEGj4vCkcPjwNLS14y73UHN5NO+iTDxPlmFlvRB5xrv2f/CpZ8H0WBeks+06S8qlfg x3mmgoay76firyNbi47GH1m8Pxa60Px9rLt1k= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr444728wfe.265.1234276423511; Tue, 10 Feb 2009 06:33:43 -0800 (PST) In-Reply-To: References: <813d89dc0902091117u1ce84ea8h39ad6a8ac8904338@mail.gmail.com> Date: Tue, 10 Feb 2009 09:33:43 -0500 Message-ID: <29a095670902100633x42ee0e1et36b26d437f12518c@mail.gmail.com> Subject: Re: Jackrabbit Lucene Query Syntax From: Alessandro Bologna To: dev@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=000e0cd181c0c72f9b0462915f62 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd181c0c72f9b0462915f62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, in xpath the predicate [bar='test'] would mean a child element that has one or more descendent text nodes that evaluates to 'test'. I think (and I may be wrong) that one issue here is that in JCR you cannot have both a property and a child node with the same name, so both expression cannot be true at the same time. Maybe then the evaluation of the xpath expression is assuming that, and causes the ambiguos behavior. In fact, in JCR, the path to the property 'bar' would be /foo/bar, the same as the path to che child 'bar'. Alessandro On Tue, Feb 10, 2009 at 6:46 AM, Ard Schrijvers wrote: > > > Hi, > > > > On Mon, Feb 9, 2009 at 8:17 PM, Dan Diephouse > > wrote: > > > This is probably a rather obvious question, but I'm trying to > > > understand the queries that Jackrabbit is putting together > > and figured > > > I'd fire off an email to see if anyone could help me out quick. My > > > xpath query is "//child[foo/@foo = 'bar']" and the lucene query is: > > > +(+(_:PROPERTIES:1:foo[bar _:PROPERTIES:1:foo[1:bar) > > +name() = {}foo) > > > +DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot), > > > +name() = > > > {}child, 1) > > > Why are there two "_:PROPERTIES:1:foo[bar" ? > > > > those two are not identical, the second one has a '1:' before > > the 'bar'. > > > > because jackrabbit cannot tell whether 'bar' is a literal of > > type STRING or NAME by just parsing XPath, it simply searches > > for both occurrences. the 1 you are seeing in the second term > > is the index internal prefix for the default namespace uri. > > Might this be the reason that if I do the query: > > //foo[bar='test'] > > The if foo does not have a node 'bar' but a property that is called bar > and equals 'test' that I get a hit? So, > > //foo[bar='test'] > //foo[@bar='test'] > > Seems to result in the same hit, where in case foo has a property > bar='test' I would only expect the second one to return a hit > > Or should //foo[bar='test'] return the hit as well? I am not sure what > [bar='test'] would actually mean. In xpath it would be a child element > with text value 'test', isn't? > > Ard > > > > > regards > > marcel > > > --000e0cd181c0c72f9b0462915f62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes,
in xpath the predicate [bar=3D'test'] would mean a child = element that has one or more descendent text nodes that evaluates to 't= est'.
 
I think (and I may be wrong) that one issue here is that in JCR you ca= nnot have both a property and a child node with the same name, so both expr= ession cannot be true at the same time. Maybe then the evaluation of the xp= ath expression is assuming that, and causes the ambiguos behavior.
In fact, in JCR, the path to the property 'bar' would be /foo/= bar, the same as the path to che child 'bar'.
 
Alessandro
 


 
On Tue, Feb 10, 2009 at 6:46 AM, Ard Schrijvers = <a.schrij= vers@onehippo.com> wrote:

> Hi,
>
> On Mon, Feb 9, 2009 at 8= :17 PM, Dan Diephouse
> <dan.diephouse@mulesource.com> wrote:
> > This is pro= bably a rather obvious question, but I'm trying to
> > understand the queries that Jackrabbit is putting together
>= ; and figured
> > I'd fire off an email to see if anyone could= help me out quick. My
> > xpath query is "//child[foo/@foo = =3D 'bar']" and the lucene query is:
> > +(+(_:PROPERTIES:1:foo[bar _:PROPERTIES:1:foo[1:bar)
> +nam= e() =3D {}foo)
> > +DescendantSelfAxisQuery(+ChildAxisQuery(_:PARE= NT:, {}testroot),
> > +name() =3D
> > {}child, 1)
>= > Why are there two "_:PROPERTIES:1:foo[bar" ?
>
> those two are not identical, the second one has a '1:'= before
> the 'bar'.
>
> because jackrabbit canno= t tell whether 'bar' is a literal of
> type STRING or NAME by= just parsing XPath, it simply searches
> for both occurrences. the 1 you are seeing in the second term
> = is the index internal prefix for the default namespace uri.

Might this be the reason that if I do the query:

//foo[bar=3D= 9;test']

The if foo does not have a node 'bar' but a property that is ca= lled bar
and equals 'test' that I get a hit? So,

//foo[ba= r=3D'test']
//foo[@bar=3D'test']

Seems to result = in the same hit, where in case foo has a property
bar=3D'test' I would only expect the second one to return a hit
=
Or should //foo[bar=3D'test'] return the hit as well? I am not = sure what
[bar=3D'test'] would actually mean. In xpath it would = be a child element
with text value 'test', isn't?

Ard

>
> r= egards
>  marcel
>

--000e0cd181c0c72f9b0462915f62--