jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Confusion regarding order of search results
Date Wed, 24 Jun 2009 13:32:09 GMT
Hi,

On Wed, Jun 24, 2009 at 14:47, Ard Schrijvers<a.schrijvers@onehippo.com> wrote:
> Hello,
>
> I am confused regarding the order of search results (jr 1.5.2 core).
> First of all, I have configured <param name="respectDocumentOrder"
> value="false"/>.
>
> Thus, I would expect if I do someting like:
>
> //*[jcr:contains(.,'foo')]
>
> that my ordering would be by @jcr:score (lucene score) descending.

no, it just means they the result nodes aren't necessarily in document order.

> If
> I print the scores, they seem instead to be random. So, this is not
> what i would expect.
>
> Secondly, when I do
>
> //*[jcr:contains(.,'foo')]  order by @jcr:score
>
> it makes sense to get results back in descending score order.

why? that's contrary to how order by is defined.

> Unfortunately, they are in ascending order. This seems to be inline
> with the spec, 6.6.3.5 Ordering Specifier ('If neither ascending nor
> descending is specified after a property name (or jcr:score(...)
> function), the default is ascending.'), but, it does not make sense
> for the jcr:score. It is strange.

no, it isn't :) it's just what you requested. order the result by
their score value in ascending order.

> And beyond that, it will lead to
> really strange behavior in combination with setLimit i think: IIUC,
> order by @jcr:score is just the default lucene scoring.

no, that's not correct. order by @jcr:score descending is the default
lucene scoring.

> This means, if
> I sort on 'order by @jcr:score' then, the first hit (lowest score)
> depends on my setLimit. If I do setLimit(1), I get the first
> authorized lucene hit, which has the highest score possible.

are you sure, this is the case? if yes, then this is a bug and should
be fixed. it should return the least relevant node.

> If I do
> setLimit(1000000000) I first get the lowest score as spec defaults to
> inverting (ascending) the lucene order. So the combination jcr:score
> which defaults to ascending, is not usefull imo, and with a setLimit()
> returns quite unexpected results.
>
> I am not sure whether jsr-283 has some changes regarding this?

no, this is still the same. higher score value means more relevant,
hence you have to sort descending to get the most relevant first.

regards
 marcel

Mime
View raw message