lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Closed: (LUCENE-526) FieldSortedHitQueue - subsequent String sorts with different locales sort identically
Date Thu, 06 Apr 2006 04:04:44 GMT
     [ http://issues.apache.org/jira/browse/LUCENE-526?page=all ]
     
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: http://issues.apache.org/jira/browse/LUCENE-526
>      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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message