Solr
  1. Solr
  2. SOLR-1815

SolrJ doesn't preserve the order of facet queries returned from solr

    Details

      Description

      Using Solrj, I wanted to sort the response of a range query based on some specific labels. For instance, using the query:

      facet=true
      &facet.query={!key= Less than 100}[* TO 99]
      &facet.query={!key=100 - 200}[100 TO 200]
      &facet.query={!key=200 +}[201 TO *]
      

      I wanted to display the response in the following order:

      Less than 100 (x)
      100 - 200 (y)
      201 + (z)
      

      independently on the values of x, y, z which are the numbers of the retrieved documents for each range.

      While Solr itself produces correctly the desired order (as specified in my query), SolrJ doesn't preserve it.

      RE: Yonik, a solution could be just to change

      _facetQuery = new HashMap<String, Integer>();
          ...to...
      _facetQuery = new Linked HashMap<String, Integer>();
      

        Activity

        Steve Radhouani created issue -
        Steve Radhouani made changes -
        Field Original Value New Value
        Labels SolrJ Solr SolrJ
        Hide
        Hoss Man added a comment -

        revising summary to clarify the problem, reclassifying as a bug, reformating description to include noformat & code tags so it doesn't try to render emoticons.

        Show
        Hoss Man added a comment - revising summary to clarify the problem, reclassifying as a bug, reformating description to include noformat & code tags so it doesn't try to render emoticons.
        Hoss Man made changes -
        Summary Sorting range queries: SolrJ doesn't preserve the order produced by Solr SolrJ doesn't preserve the order of facet queries returned from solr
        Issue Type Improvement [ 4 ] Bug [ 1 ]
        Description Using Solrj, I wanted to sort the response of a range query based on some specific labels. For instance, using the query:

        facet=true
        &facet.query={!key= Less than 100}[* TO 99]
        &facet.query={!key=100 - 200}[100 TO 200]
        &facet.query={!key=200 +}[201 TO *]

        I wanted to display the response in the following order:

        Less than 100 (x)
        100 - 200 (y)
        201 + (z)

        independently on the values of x, y, z which are the numbers of the retrieved documents for each range.

        While Solr itself produces correctly the desired order (as specified in my query), SolrJ doesn't preserve it.

        RE: Yonik, a solution could be just to change

            _facetQuery = new HashMap<String, Integer>();
        to
            _facetQuery = new Linked HashMap<String, Integer>();

         
        Using Solrj, I wanted to sort the response of a range query based on some specific labels. For instance, using the query:

        {noformat}
        facet=true
        &facet.query={!key= Less than 100}[* TO 99]
        &facet.query={!key=100 - 200}[100 TO 200]
        &facet.query={!key=200 +}[201 TO *]
        {noformat}

        I wanted to display the response in the following order:

        {noformat}
        Less than 100 (x)
        100 - 200 (y)
        201 + (z)
        {noformat}

        independently on the values of x, y, z which are the numbers of the retrieved documents for each range.

        While Solr itself produces correctly the desired order (as specified in my query), SolrJ doesn't preserve it.

        RE: Yonik, a solution could be just to change
        {code}
        _facetQuery = new HashMap<String, Integer>();
            ...to...
        _facetQuery = new Linked HashMap<String, Integer>();
        {code}
         
        Hide
        Yonik Seeley added a comment -

        I'll go ahead and make this change soon if there are no objections.

        As it relates to SolrJ, HashMap vs LinkedHashMap for facet queries will be completely inconsequential.
        The only potential burden here lies with the server side - is there some reason solr might not want to return them in order in the future? I really can't think of a realistic reason why not.

        Show
        Yonik Seeley added a comment - I'll go ahead and make this change soon if there are no objections. As it relates to SolrJ, HashMap vs LinkedHashMap for facet queries will be completely inconsequential. The only potential burden here lies with the server side - is there some reason solr might not want to return them in order in the future? I really can't think of a realistic reason why not.
        Hide
        Yonik Seeley added a comment -

        Committed. I almost didn't add a CHANGES entry this is so trivial... if others agree we could just remove and lessen the amount of noise people need to read through.

        Show
        Yonik Seeley added a comment - Committed. I almost didn't add a CHANGES entry this is so trivial... if others agree we could just remove and lessen the amount of noise people need to read through.
        Yonik Seeley made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.5 [ 12313566 ]
        Resolution Fixed [ 1 ]
        Hide
        Hoss Man added a comment -

        Correcting Fix Version based on CHANGES.txt, see this thread for more details...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Show
        Hoss Man added a comment - Correcting Fix Version based on CHANGES.txt, see this thread for more details... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E
        Hoss Man made changes -
        Fix Version/s 3.1 [ 12314371 ]
        Fix Version/s 4.0 [ 12314992 ]
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1.0 release

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1.0 release
        Grant Ingersoll made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        3d 13h 30m 1 Yonik Seeley 14/Mar/10 05:55
        Resolved Resolved Closed Closed
        381d 9h 50m 1 Grant Ingersoll 30/Mar/11 15:45

          People

          • Assignee:
            Unassigned
            Reporter:
            Steve Radhouani
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development