Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mpermar@gmail.com designates
 64.233.184.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=fgSJ+IfO8HkGH6Di8d26+TSwIFNRWMmD6zDtz7lA5v5/HcRLo8aO81OpJlKEWnn88Ctyn0KJZfGmo/hA4ywz+gZAsOSedlWumUxAHnR44EzO7tYE1FNbf8WGAO/F7G6cP55wHwhm/Di4YGTDDzvQP+2ommeA+1y8MCHRkMD8/AE=
Message-ID: <8fa1023f0601030314n305a450dx9384ebe12c52e343@mail.gmail.com>
Date: Tue, 3 Jan 2006 12:14:20 +0100
From: Martin Perez <mpermar@gmail.com>
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Strange search behaviour
In-Reply-To: <d97b4c170601030306v58ece55cv70d29708cfa8d316@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3340_27038055.1136286860593"
References: <8fa1023f0601030124i624d1f97o9b65133dc47e242@mail.gmail.com>
	 <8fa1023f0601030128q53666b49g50ed3b9bdc102eb9@mail.gmail.com>
	 <d97b4c170601030306v58ece55cv70d29708cfa8d316@mail.gmail.com>

------=_Part_3340_27038055.1136286860593
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks for the tip Marcel. I'll try it :)

On 1/3/06, Marcel Reutegger <marcel.reutegger@day.com> wrote:
>
> I assume that the returned nodes are from the jcr:system tree which
> contains versions of your nodes and node representations of your
> nodetypes.
>
> Regarding performance, per default the query handler is configured to
> return nodes in document order. This means that the query handler will
> read all result nodes and order them how they appear in the workspace.
> In your case using a XMLPersistenceManager this  might not the the
> most efficient setup ;)
>
> You can disable document order on result nodes with the following
> parameter in the SearchIndex tag:
> name=3D"respectDocumentOrder" value=3D"false"
>
> If you still have performance problems or think that the query returns
> wrong results please post a jira issue with instructions how to
> reproduce.
>
> regards
> marcel
>
> On 1/3/06, Martin Perez <mpermar@gmail.com> wrote:
> > Hi people, I hope you all a good new year.
> >
> > Today I have been testing my repository and I found a strange search
> > behaviour that make me thought that it could be some bug on the search
> > algorithm.
> >
> > Let's see. First of all, I'm using XMLPersistenceManager. I had one big
> > repository with 500..1000 documents. All those documents had the conten=
t
> > indexed using the available text filters. Next I created a smaller
> > repository with only two nodes, also with their content indexed with
> > available text filters.
> >
> > Then I performed a xpath query over the smaller repository. Something
> like
> > this://*[@jcr:primaryType=3D'nt:file' and
> > jcr:contains(@jlib:keywords,'test')]. As you see, is very simple, it
> > searches for a term under a keywords property. That query went fine and
> > returned very fast.
> >
> > But the problem, is when I performed another query. Something like this=
:
> > //*[@jcr:primaryType=3D'nt:resource' and jcr:contains(.,'test')] This
> query
> > tries to search the same term on the node binary contents. The query wa=
s
> > very very very slooooooow. So I decided to debug that query, and I saw
> that
> > the NodeIterator returned had over 270 nodes !!! How it can have 270
> nodes
> > if the repository won't have more than 10? I suppose that is because th=
e
> > query was done also over the first repository, but then, is the XPath
> query
> > wrong?
> >
> > Thanks for your help!
> >
> > Martin
> >
> >
>

------=_Part_3340_27038055.1136286860593--