[ http://issues.apache.org/jira/browse/LUCENE-526?page=comments#action_12371341 ]
Yonik Seeley commented on LUCENE-526: ------------------------------------- Thanks for looking into this Paul! A quick pointer... a Multisearcher uses different sorting code than an IndexSearcher. IIRC, MultiSearcher uses FieldDocSortedHitQueue and an IndexSearcher uses FieldSortedHitQueue. It wouldn't be the first time that a bug was fixed in one but forgotten about in the other. > 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.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]
