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

        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.
        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.
        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
        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

          People

          • Assignee:
            Unassigned
            Reporter:
            Steve Radhouani
          • Votes:
            0 Vote for this issue
            Watchers:
            1 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