[
https://issues.apache.org/jira/browse/SOLR-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257173#comment-15257173
]
Dennis Gove edited comment on SOLR-8467 at 4/25/16 10:31 PM:
-------------------------------------------------------------
bq. 1) We need some tests for Streaming Expressions with multi-params. It may
be that the expression parser needs to be changed to support this. If that's
the case we should hold off until we get that working.
I don't think there'll need to be any change here. For the source streams we
pull out all *known* named parameters and then all other parameters are just
passed along to Solr as standard params. For those which are just passed along
there shouldn't be any consideration of the parameter names and if I recall
correctly duplicate names are allowable.
was (Author: dpgove):
> 1) We need some tests for Streaming Expressions with multi-params. It may be
> that the expression parser needs to be changed to support this. If that's the
> case we should hold off until we get that working.
I don't think there'll need to be any change here. For the source streams we
pull out all *known* named parameters and then all other parameters are just
passed along to Solr as standard params. For those which are just passed along
there shouldn't be any consideration of the parameter names and if I recall
correctly duplicate names are allowable.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
