jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Perez <mper...@gmail.com>
Subject Re: Strange search behaviour
Date Tue, 03 Jan 2006 11:14:20 GMT
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="respectDocumentOrder" value="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 content
> > 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='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='nt:resource' and jcr:contains(.,'test')] This
> query
> > tries to search the same term on the node binary contents. The query was
> > 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 the
> > query was done also over the first repository, but then, is the XPath
> query
> > wrong?
> >
> > Thanks for your help!
> >
> > Martin
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message