lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Riddle" <>
Subject Re: Possible bug in FieldSortedHitQueue?
Date Fri, 17 Mar 2006 08:06:01 GMT
Hej Paul,

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.

Looking at FiledSortedHitQueue it looks like the bug is in
That method returns a ScoreDocComparator of type SortField.String . The
only looks at the field, type and custom ScoreDocComparator used for
equality and hashcode.
String does not have any Locale information associated with it.  So the
first ScoreDocCompartor you
are creating in your application is the one getting cached thats the one
being used.

heres a small patch that should fix it. I have not have time to test. You
will need to add an import of as well java.lang.Arrays;

      //This needs to be custom or the equals will not be called correctly
in FieldCacheEntry.Entry#equals
      public int sortType() {
        return SortField.CUSTOM;
        //implement equals and hashcode taking in account the Collator used
        //being based on the locale will allow sorting by more than one
      public boolean equals(Object o) {
          if (this == o) return true;
          if (o == null || getClass() != o.getClass()) return false;
          final TestScoreDocComparator that = (TestScoreDocComparator) o;
          if (collator != null ? !collator.equals(that.collator) :
that.collator != null) return false;
          return Arrays.equals(index, that.index);

        public int hashCode() {
            return (collator != null ? collator.hashCode() : 0);

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message