lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Closed: (LUCENE-526) FieldSortedHitQueue - subsequent String sorts with different locales sort identically
Date Thu, 06 Apr 2006 04:04:44 GMT
     [ ]
Yonik Seeley closed LUCENE-526:

    Fix Version: 2.0
     Resolution: Fixed
      Assign To: Yonik Seeley

I've reviewed and committed these patches.
Thanks again Paul!

> 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
>     Assignee: Yonik Seeley
>      Fix For: 2.0
>  Attachments: LUCENE-526-b.txt, LUCENE-526-c.txt, LUCENE-526-d.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