Erick Erickson created SOLR-11075:
-------------------------------------
Summary: Refactor handling of params in CloudSolrStream and
FacetStream
Key: SOLR-11075
URL: https://issues.apache.org/jira/browse/SOLR-11075
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Assignee: Erick Erickson
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.
[~dpgove][~joel.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
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
