[jira] [Commented] (SOLR-8467) CloudSolrStream and FacetStream should take a SolrParams object rather than a Map to allow more complex Solr queries to be specified

["Erick Erickson (JIRA)" <ji...@apache.org>]

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

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

[~joel.bernstein][~dpgove] This is getting reasonably close to being committable, but I ran into something I wanted to run past you.

in GatherNodeStream.JoinRunner (starting line 386 in current trunk) there's some manipulation of the params. Starting at line 412 there's this bit:

      if(queryParams.containsKey("fl")) {
        String flString = (String)queryParams.get("fl");
        String[] flArray = flString.split(",");
        for(String f : flArray) {
          flSet.add(f.trim());
        }
      }

Since flSet is a HashSet, doesn't this fold all of the "fl" parameters into a single entry so if you have fl=a,b,c the result would only be 'c'? 

And what's right here anyway? Does it make sense to concatenate the "fl" parameters from the queryParams to the joinParams and add the "special" fl params ('gather' and 'traverseTo' and metrics)? Or should the joinParams just contain the "special" params?

I don't really see how to return more fls in the tuple that GatherNodesStream returns, if it should please enlighten me ;)



> 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-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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org