[ http://issues.apache.org/jira/browse/LUCENE-526?page=all ]
Paul Cowan updated LUCENE-526:
------------------------------
Attachment: LUCENE-526-d.txt
Another patch, to fix the last-described issue.
Turns out the problem was the FieldSortedHitQueue constructor; when building
the fields[] array, it was ignoring the locale if there was one. The
comparators[] array is correct, so FieldSortedHitQueue sorts fine, but the
topdocs that come out of the search have no locale in the fields[]; therefore,
the in-order insertion in MultiSearcher screws up the order as it now no longer
knows what locale to use.
Test case from LUCENE-526-c.txt now passes.
> 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
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
