[jira] [Commented] (SOLR-11075) Refactor handling of params in CloudSolrStream and FacetStream

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (SOLR-11075) Refactor handling of params in CloudSolrStream and FacetStream

JIRA jira@apache.org

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

Erick Erickson commented on SOLR-11075:

bq: I do not recall any particular reason why parameter values are joined with a comma instead of adding the parameter for each value.

I'm pretty sure it was unintentional on my part when we went from Map<> to SolrParams in SOLR-8467. That bit went from
and I said "Hmm, looks like the array of strings should be combined with a comma". Wrong. Of course the old way wouldn't have worked for this case anyway since you couldn't specify two "fq" clauses.

Anyway, it's good to have your perspective, I'll commit this soon.

> 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

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]