Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-11075

Refactor handling of params in CloudSolrStream and FacetStream

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 7.1, 8.0
    • None
    • None

    Description

      We started to look more closely at how toExpression is used in these classes and the more we look the more puzzled we became (Varun and I that is).

      Is there any reason other than history why the params are pulled apart then reconstructed into comma-separated lists when there are more than one of any particular parameter? I suspect than when I worked on SOLR-8467 I didn't delve deeply enough here.

      dpgovejoel.bernstein risdenk in particular we'd like your opinion. Arguably this is going to lead to anomalies, i.e. differences in what streaming selects .vs. what standard Solr would select.

      For instance, let's say the user puts two "q" parameters in. Standard Solr parsing uses the first one encountered. what happens when we get q=clause1,clause2 as a result of the toExpression is anybody's guess. It just shouldn't be different than straight-up Solr IMO.

      "fl" parameters on the other hand are all honored, as are "fq" clauses.

      Multiple "sort" clauses it appears first one wins.

      So my question is whether it makes sense to just add the parameter multiple times, presumably reflecting the actual query.

      Assigning to myself but someone else should feel free to take it

      Attachments

        1. SOLR-11075.patch
          4 kB
          Erick Erickson

        Activity

          People

            erickerickson Erick Erickson
            erickerickson Erick Erickson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: