[
https://issues.apache.org/jira/browse/SOLR-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-8467:
---------------------------------
Attachment: SOLR-8467.patch
Cleaned up patch. There are still a couple of nocommits that I'd especially
like another set of eyes on, I'm not entirely comfortable with those bits of
code.
This patch removes a bunch of nocommits and old code I commented out. It also
tries to regularize the member variables as SolrParams rather than
ModifiableSolrParams. While doing that I notices a couple of places where the
member variable was actually being modified, things like adding &distrib=false.
That seems like A Bad Thing.
There's some junk in here where I deprecated c'tors that take a Map<String,
String> and added a new (preferred) one that takes a SolrParams object. What do
y'all think about taking out the c'tor that takes a Map? Is all this code new
enough that we don't need to carry that baggage along? I took out the bits in
the tests where it randomly chooses the old or new c'tor as they were in there
just for preliminary testing....
An embarrassingly large amount of this patch is the re-formatted schema.xml
file. I took out the long-deprecated <types> and <fields> tags and re-indented
(just a quick keystroke in IntelliJ). I did have to add one field type though
*_dvs for new tests so there's at least one substantive change (not really sure
it's necessary though)...
So, getting close to committing. Do we really want to wait for 6.1? If we take
the c'tors that take a Map out the sooner the better.
Perhaps mark those c'tors as "experimental"? I doubt we'd be inconveniencing
too many people at this point since this is so new.
> 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-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]