lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Cowan (JIRA)" <>
Subject [jira] Updated: (LUCENE-526) FieldSortedHitQueue - subsequent String sorts with different locales sort identically
Date Tue, 21 Mar 2006 23:21:02 GMT
     [ ]

Paul Cowan updated LUCENE-526:

    Attachment: LUCENE-526-c.txt

It seems that there are more issues with locale-based sorting than just the above.

Attached is LUCENE-526-c.txt, a new version of the patch which adds another
test case. Even after LUCENE-526-b is applied, and hence the first new test passes, the second

The second test takes the existing IndexSearcher, wraps it up as the only Searcher in a MultiSearcher,
and then searches the MultiSearcher. It seems that the results come out of the IndexSearcher
in the right order, but when MultiSearcher merges the results from all of its Searchers (in
this case, just one) the local-specific sorting isn't done correctly.

I will investigate further today, with a patch hopefully to follow.

> FieldSortedHitQueue - subsequent String sorts with different locales sort identically
> -------------------------------------------------------------------------------------
>          Key: LUCENE-526
>          URL:
>      Project: Lucene - Java
>         Type: Bug
>   Components: Search
>     Versions: 1.9
>     Reporter: Paul Cowan
>  Attachments: LUCENE-526-b.txt, LUCENE-526-c.txt, LUCENE-526.txt
> From my own post to the java-user list. I have looked into this further and am sure it's
a bug.
> ---
> It seems to me that there's a possible bug in FieldSortedHitQueue, specifically in getCachedComparator().
This is showing up on our 1.4.3 install, but it seems from source code inspection that if
it's a bug, it's in 1.9.1 also.
> The issue shows up when you need to sort results from a given IndexReader multiple times,
using different locales. On line 180 (all line numbers from the 1.9.1 code), we have this:
> ScoreDocComparator comparator = lookup (reader, fieldname, type, factory);
> Then, if no comparator is found in the cache, a new one is created (line 193) and then
stored in the cache (line 202). HOWEVER, both the cache lookup() and store() do NOT take into
account locale; if we, on the same index reader, try to do one search sorted by Locale.FRENCH
and one by Locale.ITALIAN, the first one will result in a cache miss, a new French comparator
will be created, and stored in the cache. Second time through, lookup() finds the cached French
comparator -- even though this time, the locale parameter to getCachedComparator() is an Italian
locale. Therefore, we don't create a new comparator and we use the wrong one to sort the results.
> It looks to me (unless I'm mistaken) that the FieldCacheImpl.Entry class should have
an additional property, .locale, to ensure that different locales get different comparators.
> ---
> Patch (well, most of one) to follow immediately.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message