jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ard Schrijvers <a.schrijv...@onehippo.com>
Subject Confusion regarding order of search results
Date Wed, 24 Jun 2009 12:47:56 GMT
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. 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.
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. 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. 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. 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?  Did
other people also experience this jcr:score ambiguous sorting?

Regards Ard

Mime
View raw message