You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2015/12/28 07:10:49 UTC

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

     [ https://issues.apache.org/jira/browse/SOLR-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-8467:
---------------------------------
    Attachment: SOLR-8647.patch

Here's the patch I've worked up so far. 

[~dpgove][~joel.bernstein] I'm particularly interested in any comments you have.

I did one gratuitous thing, in StreamingTest moved all of the del *:*/commits to the beginning of the methods, I think it's fragile to depend on old tests cleaning themselves up, I vastly prefer the test that needs things to be in some state to insure that state.

I also noticed that the tests here rarely close their CloudSolrStreams, is that intentional? Or harmless?

Anyway, there are still some nocommits in there, and I'm pretty hazy on whether the changes I made to streaming expressions were the right things. All the tests pass so at least that's a Good Thing.

Is there any good reason we don't have access to commons.lang? In particular StringUtils.join would be useful in one instance. It's easy enough to write a function, but I bet the one in commons is more efficient.

So I did comment out the c'tors that take a Map completely and chased down all the places I found that referenced that format. I then un-commented them for back-compat, but I'm pretty sure I found all the places in Solr code that uses those c'tors and then replaced them.

You'll note that tests in StreamingTest randomly chooses one c'tor or the other just to exercise both. Of course if we really deprecate the old version that'll have to be changed, but that's trivial.

Let me know what you think. I'll be away for a couple of days so if I'm kind of silent you'll know why.

> CloudSolrStream 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-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