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

Refactor handling of params in CloudSolrStream and FacetStream



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


      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


        1. SOLR-11075.patch
          4 kB
          Erick Erickson



            erickerickson Erick Erickson
            erickerickson Erick Erickson
            0 Vote for this issue
            4 Start watching this issue