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

Erick Erickson commented on SOLR-8467:
--------------------------------------

This is what I was wondering when I asked "What's right here anyway?". If I'm 
reading your response correctly, we can simply throw away the original "fl" 
params because we don't care about them anyway right? And uniquify the rest 
with a set.


> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map<String, String> to allow more complex Solr queries to be specified
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-8467
>                 URL: https://issues.apache.org/jira/browse/SOLR-8467
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-8467.patch, SOLR-8467.patch, SOLR-8647.patch, 
> SOLR-8647.patch
>
>
> Currently, it's impossible to, say, specify multiple "fq" clauses when using 
> Streaming Aggregation due to the fact that the c'tors take a Map of params.
> Opening to discuss whether we should
> 1> deprecate the current c'tor
> and/or
> 2> add a c'tor that takes a SolrParams object instead.
> and/or
> 3> ???
> I don't see a clean way to go from a Map<String, String> to a 
> (Modifiable)SolrParams, so existing code would need a significant change. I 
> hacked together a PoC, just to see if I could make CloudSolrStream take a 
> ModifiableSolrParams object instead and it passes tests, but it's so bad that 
> I'm not going to even post it. There's _got_ to be a better way to do this, 
> but at least it's possible....



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to