[ http://issues.apache.org/jira/browse/LUCENE-526?page=all ]
Paul Cowan updated LUCENE-526:
------------------------------
Attachment: LUCENE-526.txt
Attached is a patch that provides an additional test case to TestSort.java for
this issue (currently fails on latest trunk code) and patches to
FieldCacheImpl.java and FieldSortedHitQueue.java which allow the test case to
pass.
This is not an idea solution as it lumbers FieldCacheImpl.Entry with a locale
field which is only used by the cache in FieldSortedHitQueue, and not the main
cache from FieldCacheImpl. This means that ONLY the FieldSortedHitQueue is
locale-aware; the FieldCache itself isn't (there are no locales used in the
interface). I thought I would provide this "prototype" patch, though, as an
example. I am open to suggestions about how best to implement this. Options
include
* subclass FieldCacheImpl.Entry into a locale-aware version, which
FieldSortedHitQueue uses
* change the FieldCache interface to take in a locale for the various
getXxxx methods (or possibly only the String ones?)
* something else I haven't thought of...?
I look forward to your thoughts.
> 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.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]
