Solr
  1. Solr
  2. SOLR-3163

FacetComponent returns list of alternate name, value instead of map for counts in JSON responses

    Details

      Description

      Facet counts for facet.field come back in JSON format like this (a list of name and values, where even positions are keys and odd positions are values).

      "facet_counts":{
      "facet_fields":{
      "u_idx":[
      "section",39663,
      "adam",6211,
      "image",3840,
      "slideshow",2480],
      ...

      unlike facet.query facet counts, which come back like this (a map of name value pairs).

      "facet_queries":

      Unknown macro: { "u_reviewdate}

      ,

      This is only for wt=json. With wt=xml, the two formats look similar.

      <lst name="facet_queries">
      <int name="u_reviewdate:[NOW-6MONTH TO NOW]">42</int>
      <int name="u_reviewdate:[NOW-1YEAR TO NOW-6MONTHS]">1561</int>
      <int name="u_reviewdate:[NOW-2YEAR TO NOW-1YEAR]">3017</int>
      <int name="u_reviewdate:[NOW-5YEAR TO NOW-2YEAR]">1538</int>
      <int name="u_reviewdate:[NOW-100YEAR TO NOW-5YEAR]">47</int>
      </lst>

      <lst name="facet_fields">
      <lst name="u_idx">
      <int name="section">39663</int>
      <int name="adam">6211</int>
      <int name="image">3840</int>
      <int name="slideshow">2480</int>
      </lst>

      I believe this is because of the use of NamedList for this data structure in FacetCountsComponent, SimpleOrderedMap should be used instead. This will produce results of facet_field counts like a map in JSON format (and keep the XML output the same).

      "facet_counts":{
      "facet_fields":{
      "u_idx":[
      "section":39663,
      "adam":6211,
      "image":3840,
      "slideshow":2480],
      ...

      This makes it consistent across different kinds of facets and is easier to consume on the client.

      There is the concern about backward compatibility (ie users are already consuming the incorrect/inconsistent format so we can't change it), but if that is not as important as consistency and ease of use, then I can supply a patch for this.

        Activity

        Hide
        Yonik Seeley added a comment -

        I believe this is because of the use of NamedList for this data structure in FacetCountsComponent, SimpleOrderedMap should be used instead.

        The use of NamedList (i.e. order is more important than access by key) was deliberate. Many JSON clients do not preserve order (or at least they didn't back when I made this decision), and order mattered to many people.

        http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters

        There's no right answer here... just different trade-offs.
        Is this still the best default? I'd like to hear what others think about the pain of using an alternating array vs the pain of having to re-sort because the JSON parser didn't preserve the order.

        Show
        Yonik Seeley added a comment - I believe this is because of the use of NamedList for this data structure in FacetCountsComponent, SimpleOrderedMap should be used instead. The use of NamedList (i.e. order is more important than access by key) was deliberate. Many JSON clients do not preserve order (or at least they didn't back when I made this decision), and order mattered to many people. http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters There's no right answer here... just different trade-offs. Is this still the best default? I'd like to hear what others think about the pain of using an alternating array vs the pain of having to re-sort because the JSON parser didn't preserve the order.
        Hide
        Sujit Pal added a comment -

        Ok, I understand. I already have a workaround to parse the NamedList as it is, so I am not blocked. Just seemed inconsistent, but now I understand why. And for those that need it, one can probably use the json.nl=map parameter. Shall I close the bug?

        Show
        Sujit Pal added a comment - Ok, I understand. I already have a workaround to parse the NamedList as it is, so I am not blocked. Just seemed inconsistent, but now I understand why. And for those that need it, one can probably use the json.nl=map parameter. Shall I close the bug?
        Hide
        Sujit Pal added a comment -

        This is a known feature and not a bug to preserve order. Closing.

        Show
        Sujit Pal added a comment - This is a known feature and not a bug to preserve order. Closing.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sujit Pal
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development