Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <44630869.1000908@gmx.net>
Date: Thu, 11 May 2006 11:48:25 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: Restricting xpath query to document text
References: <4102828.post@talk.nabble.com> <44508BB4.8010307@gmx.net>
 <4320864.post@talk.nabble.com>
In-Reply-To: <4320864.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

thomasg wrote:
> Hi Marcel,
> 
> I've just been looking at a some more typical queries that our system will
> need to run and am finding a (related) but more serious problem using
> jcr:like. 
> A query such as this works fine:
> String queryString = "//element(*, axxia:resource)[jcr:like(@axxia:title,
> '%inking%Java%')]"; 
> 
> But how can you specify that you want the document text to be like
> '%inking%Java%'? Is it currently the case that jcr:like can only search
> properties and not the document text?

Yes, in JSR-170 the jcr:like() function is specified to only work on String 
properties. And I think this makes sense, because a like operation on a potentially 
large text which is not tokenized may be quite expensive. you should then rather use 
jcr:contains which also works on fulltext indexed binary properties.

> Using jcr:contains the situation is ok since jcr:contains(., 'word')
> searches the document text, even though you can't specify 'ONLY the document
> text and not other properties'. 

I think this is a reasonable extension that we should consider in jackrabbit.

it is tracked with this issue:
http://issues.apache.org/jira/browse/JCR-415

regards
  marcel