[ 
https://issues.apache.org/jira/browse/SOLR-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16088984#comment-16088984
 ] 

ASF subversion and git services commented on SOLR-11075:
--------------------------------------------------------

Commit dc28374bea6592c1ba1f9b3436427bf5d7c9edeb in lucene-solr's branch 
refs/heads/branch_7x from Erick
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dc28374 ]

SOLR-11075: Refactor handling of params in CloudSolrStream and FacetStream

(cherry picked from commit b17ec14)


> 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
>         Attachments: SOLR-11075.patch
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to