Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-453

Using MultiSearcher and ParallelMultiSearcher can change the sort order.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.9
    • Component/s: core/search
    • Labels:
      None
    • Environment:

      Checked with revision 314961 on 2005-10-12

      Description

      When using multiple sort criteria the first criterium that indicates a difference should be used.
      When a field does not exist for a given document, special rules apply.
      From what I see in the code, it is sorted as 0 for integer and float fields, and null Strings are sorted before others.

      This works correctly in both Lucene 1.4.3 and in trunk as long as you use a single IndexSearcher (except perhaps in special cases, see other bug reports like LUCENE-374).

      However, in MultiSearcher and ParallelMultiSearcher, the results of the separate IndexSearchers are merged and there an error occurs.
      The bug is located in FieldDocSortedHitQueue.

      It can even be demonstrated by passing a single indexSearcher to a MultiSearcher.

      TestCase and patch follow.

      1. FieldDocSortedHitQueue.diff
        1 kB
        Luc Vanlerberghe
      2. TestSort.diff
        4 kB
        Luc Vanlerberghe

        Activity

        Hide
        lvl Luc Vanlerberghe added a comment -

        The two assertMatches using the full index will pass.
        The same assertMatches using a MultiSearcher or a ParallelMultiSearcher will fail.

        Show
        lvl Luc Vanlerberghe added a comment - The two assertMatches using the full index will pass. The same assertMatches using a MultiSearcher or a ParallelMultiSearcher will fail.
        Hide
        lvl Luc Vanlerberghe added a comment -

        This fixes the case where both Strings are null.

        Show
        lvl Luc Vanlerberghe added a comment - This fixes the case where both Strings are null.
        Hide
        lucenebugs@danielnaber.de Daniel Naber added a comment -

        What about the other "case" statements in FieldDocSortedHitQueue that return 1 or -1 but never 0. Should these be patched the same way?

        Show
        lucenebugs@danielnaber.de Daniel Naber added a comment - What about the other "case" statements in FieldDocSortedHitQueue that return 1 or -1 but never 0. Should these be patched the same way?
        Hide
        yseeley@gmail.com Yonik Seeley added a comment -

        most of the other cases are guaranteed to never have null values (except for perhaps CUSTOM)?

        Show
        yseeley@gmail.com Yonik Seeley added a comment - most of the other cases are guaranteed to never have null values (except for perhaps CUSTOM)?
        Hide
        yseeley@gmail.com Yonik Seeley added a comment -

        Thanks for the patch Luc!
        I've applied it to the current dev version (1.9).

        Show
        yseeley@gmail.com Yonik Seeley added a comment - Thanks for the patch Luc! I've applied it to the current dev version (1.9).

          People

          • Assignee:
            yseeley@gmail.com Yonik Seeley
            Reporter:
            lvl Luc Vanlerberghe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development