You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Ard Schrijvers <a....@onehippo.com> on 2009/06/24 14:47:56 UTC
Confusion regarding order of search results
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
Re: Confusion regarding order of search results
Posted by Ard Schrijvers <a....@onehippo.com>.
>>
>> what do you mean 'no'...I said I would expect it, and IMO it makes sense.
>
> I'm sorry. I didn't mean to be rude.
no problem, was a joke of mine, i forgot the smiley i now realize :-)
>
>> If in lucene you do not specify an order, you'll get back the highest scores first.
>
> that true. however I'm not sure this is always desirable. what if I'm
> just interested in the result set and not a particular order? then the
> ordering is irrelevant and just costs more CPU cycles.
I thought lucene would always order...but I guess you are right..OTOH,
in lucene Hits I see:
TopDocs topDocs = (sort == null) ? searcher.search(weight, filter, n)
: searcher.search(weight, filter, n, sort);
This gives me the idea, that with no sort, Hits are returned by
relevance. AFAIK, returning hits by doc id is done by specifying a
sort, namely SortField.DOC
/** Sort by document number (index order). Sort values are Integer and lower
* values are at the front. */
public static final int DOC = 1;
I'll do some tests and will provide the results
>
> at some point in the discussion of the EG for JSR 170 the score was
> actually named rank, which would have better matched your expectation.
> assuming that a lower rank value is better. but then it was decided to
> call it score where higher values mean more relevant.
Yes, I see, thx
>
>> An order by score would make a perfect default if respectDocumentOrder is set to false.
>
> see also my comment above. however we could default to 'order by
> @jcr:score descending' if there is a fulltext search clause in the
> query. WDYT?
I think this would be more in line what people would expect, so +1
>>
>> Bottom line, I'll default to adding 'order by @jcr:score descending' when no order is
>> specified :-))
>
> or we change jackrabbit to do that if there is a fulltext clause (aka
> jcr:contains()) in the query :)
I will try to find why the results seem to be not by default according
lucene scoring...I would think this is namely the default with no sort
as described above: I must be wrong somewhere I guess.
I think it would make sense, that if we have no order by, we default
to the lucene order...I'll test this now to see whether I am wrong
about the default lucene ordering.
Furthermore I can live without the default 'order by @jcr:score
descending' because I now know this. It depends on whether we think
other people/users will benefit from this. WDYT?
Regards Ard
>
> regards
> marcel
>
>> thx for your replies Marcel
>>
>> Ard
>>
>>>
>>>
>>> regards
>>> marcel
>>
>
Re: Confusion regarding order of search results
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi,
2009/6/24 Ard Schrijvers <a....@onehippo.com>
>
>
> On Wed, Jun 24, 2009 at 3:32 PM, Marcel Reutegger <ma...@gmx.net> wrote:
>>
>> Hi,
>>
>> On Wed, Jun 24, 2009 at 14:47, Ard Schrijvers<a....@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.
>
> what do you mean 'no'...I said I would expect it, and IMO it makes sense.
I'm sorry. I didn't mean to be rude.
> If in lucene you do not specify an order, you'll get back the highest scores first.
that true. however I'm not sure this is always desirable. what if I'm
just interested in the result set and not a particular order? then the
ordering is irrelevant and just costs more CPU cycles.
>>
>>
>> > 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.
>
> Yeah I understand, and I think the definition would have been way better if it would have
> made an exception for the score: Who ever want to have the results with the lowest
> score first? Those queries must be really rare imo.
at some point in the discussion of the EG for JSR 170 the score was
actually named rank, which would have better matched your expectation.
assuming that a lower rank value is better. but then it was decided to
call it score where higher values mean more relevant.
>> > 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.
>
> If I do not specify an order, I get the lowest score first. I try to say that that is really an odd default for score. I think this is quite straightforward (furthermore, though I must check it,it is if i recall correctly, far more expensive with a lucene query to get the lowest scores instead of the highest)
>
>>
>> > 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.
>
> Sry, I was not clear enough: what I am saying, is that if in SearchIndex you do:
>
> hits = searcher.search(query);
>
> then afaik, you'll get a Hits object in lucene sorted on score (descending, as this makes
> sense as a default). For some reason, the ordering when I get back the nodes is shuffled. I
> don't understand why.
the technical reason is that jackrabbit creates a lucene Sort instance
with an empty fields arrays. IIUC that will result in nodes being
ordered by lucene document number.
> An order by score would make a perfect default if respectDocumentOrder is set to false.
see also my comment above. however we could default to 'order by
@jcr:score descending' if there is a fulltext search clause in the
query. WDYT?
>>
>>
>> > 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.
>
> I was not sure, I only did it by reasoning, but now i see:
>
> if (NameConstants.JCR_SCORE.equals(orderProps[i])) {
> // order on jcr:score does not use the natural order as
> // implemented in lucene. score ascending in lucene means that
> // higher scores are first. JCR specs that lower score values
> // are first.
> sortFields.add(new SortField(null, SortField.SCORE, orderSpecs[i]));
> }
>
>
> so my claim is incorrect
>
>>
>>
>> > 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.
>
> Perhaps a matter of taste...I would have always opted for the highest scores first as a
> default, and thus make an explicit exception for score.
>
> Bottom line, I'll default to adding 'order by @jcr:score descending' when no order is
> specified :-))
or we change jackrabbit to do that if there is a fulltext clause (aka
jcr:contains()) in the query :)
regards
marcel
> thx for your replies Marcel
>
> Ard
>
>>
>>
>> regards
>> marcel
>
Re: Confusion regarding order of search results
Posted by Ard Schrijvers <a....@onehippo.com>.
On Wed, Jun 24, 2009 at 3:32 PM, Marcel Reutegger
<ma...@gmx.net>wrote:
> Hi,
>
> On Wed, Jun 24, 2009 at 14:47, Ard Schrijvers<a....@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.
what do you mean 'no'...I said I would expect it, and IMO it makes sense. If
in lucene you do not specify an order, you'll get back the highest scores
first.
>
>
> > 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.
Yeah I understand, and I think the definition would have been way better if
it would have made an exception for the score: Who ever want to have the
results with the lowest score first? Those queries must be really rare imo.
>
>
> > 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.
If I do not specify an order, I get the lowest score first. I try to say
that that is really an odd default for score. I think this is quite
straightforward (furthermore, though I must check it,it is if i recall
correctly, far more expensive with a lucene query to get the lowest scores
instead of the highest)
>
>
> > 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.
>
Sry, I was not clear enough: what I am saying, is that if in SearchIndex you
do:
hits = searcher.search(query);
then afaik, you'll get a Hits object in lucene sorted on score (descending,
as this makes sense as a default). For some reason, the ordering when I get
back the nodes is shuffled. I don't understand why. An order by score would
make a perfect default if respectDocumentOrder is set to false.
>
> > 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.
I was not sure, I only did it by reasoning, but now i see:
if (NameConstants.JCR_SCORE.equals(orderProps[i])) {
// order on jcr:score does not use the natural order as
// implemented in lucene. score ascending in lucene means
that
// higher scores are first. JCR specs that lower score
values
// are first.
sortFields.add(new SortField(null, SortField.SCORE,
orderSpecs[i]));
}
so my claim is incorrect
>
> > 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.
Perhaps a matter of taste...I would have always opted for the highest scores
first as a default, and thus make an explicit exception for score.
Bottom line, I'll default to adding 'order by @jcr:score descending' when no
order is specified :-))
thx for your replies Marcel
Ard
>
> regards
> marcel
>
Re: Confusion regarding order of search results
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi,
On Wed, Jun 24, 2009 at 14:47, Ard Schrijvers<a....@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