Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1656401630.1142989222522.JavaMail.jira@ajax>
Date: Wed, 22 Mar 2006 01:00:22 +0000 (GMT)
From: "Paul Cowan (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Updated: (LUCENE-526) FieldSortedHitQueue - subsequent
 String sorts with different locales sort identically
In-Reply-To: <1522324756.1142835930720.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org