Solr
  1. Solr
  2. SOLR-542

"fl" should be a multi-value param

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: search
    • Labels:
      None
    • Environment:

      Java 6
      Linux (CentOS)

      Description

      We've got the "fq" working in the "appends" section (<lst/> element) of our requestHandlers. We'd like to add other attributes - in particular, the "fl" attribute, so that, regardless of query, the user is ensured of getting some minimum set of fields in the results. Yet, when we a setting for "fl" to the "appends" section it has no affect.

      On a separate note, when a user specified &fl=score in the URL, the results are those one should get for &fl=*,score – that is, all fields, not just the score, is/are returned.

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          this isn't actually a bug – fl isn't currently a "multi-value" param (and isn't advertised as such) so "appending" doesn't mean anything...

          http://wiki.apache.org/solr/CommonQueryParameters#fl

          it's a perfectly reasonable improvement to suggest that fl should be multi-value ... i've updated the issue type/summary to reflect this.

          NOTE: please open a separate issue about fl=score vs fl=*,score ... i think the orriginal assumption was that without at least one other field the score is useless, but that's not entirely true given that you might be getting all of hte other data you care about from the highlighting section.

          Show
          Hoss Man added a comment - this isn't actually a bug – fl isn't currently a "multi-value" param (and isn't advertised as such) so "appending" doesn't mean anything... http://wiki.apache.org/solr/CommonQueryParameters#fl it's a perfectly reasonable improvement to suggest that fl should be multi-value ... i've updated the issue type/summary to reflect this. NOTE: please open a separate issue about fl=score vs fl=*,score ... i think the orriginal assumption was that without at least one other field the score is useless, but that's not entirely true given that you might be getting all of hte other data you care about from the highlighting section.
          Hide
          Peter Wolanin added a comment -

          This would be a welcome addition to make the parameter handling more consistent.

          Show
          Peter Wolanin added a comment - This would be a welcome addition to make the parameter handling more consistent.
          Hide
          Yonik Seeley added a comment -

          Agree. Esp when we start thinking about how to do pseudo-fields.
          Just using "fl" for this seems attractive.

          fl=geodist()
          fl=

          {!key=dist}

          geodist($pt,store)

          Show
          Yonik Seeley added a comment - Agree. Esp when we start thinking about how to do pseudo-fields. Just using "fl" for this seems attractive. fl=geodist() fl= {!key=dist} geodist($pt,store)
          Hide
          Ryan McKinley added a comment -

          this will be part of SOLR-2444

          Show
          Ryan McKinley added a comment - this will be part of SOLR-2444
          Hide
          Ryan McKinley added a comment -

          part of SOLR-2444

          Show
          Ryan McKinley added a comment - part of SOLR-2444

            People

            • Assignee:
              Unassigned
              Reporter:
              Ezra Epstein
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development