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

2016-05-09 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on SOLR-8467:
---

Commit 73b4defc0751bd0cd2ad999e3a4e6c593fd0fb1c in lucene-solr's branch 
refs/heads/branch_6x from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73b4def ]

SOLR-8467: CloudSolrStream and FacetStream should take a SolrParams object 
rather than a Map to allow more complex Solr queries to be 
specified


> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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-8467.patch, 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 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

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

2016-05-09 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on SOLR-8467:
---

Commit f4359ff8ffd96253ba610865c5e29172307c3c7a in lucene-solr's branch 
refs/heads/master from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f4359ff ]

SOLR-8467: CloudSolrStream and FacetStream should take a SolrParams object 
rather than a Map to allow more complex Solr queries to be 
specified


> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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-8467.patch, 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 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

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

2016-05-09 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

Ok, sounds good.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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-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 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

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

2016-05-05 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

Every day or two I pull the latest master and re-apply this set of changes. 
Today was the first day that was at all difficult.

Please ping me before you start working on it, it may by that I just haven't 
put up my most recent patch.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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-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 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

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

2016-05-05 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

So, the tests are going have to be reworked. I said I'd take this on if this 
ticket fell far behind master. At the time I didn't realize how far behind it 
would get so quickly. I should have time to review and rework the tests for 
this ticket over the next week.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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-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 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

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

2016-04-27 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

I think I'd to take some time to review before it's committed. If I can get the 
review done before 6.1 let's go for it. The major 6.1 streaming work is all in 
trunk now anyway, so it won't cause issues with that work.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-26 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

Same thing (Unable to build keystore) happens on unmodified trunk, so I'm 
pretty confident that's not a result of this patch.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-26 Thread Erick Erickson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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 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

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

2016-04-26 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

OK, I reviewed the fl handling in gather nodes and it is correct for how params 
are currently being handled. What it's doing is deriving the field list from 
the metrics and uniquing them. We'll have to adjust how this is working as part 
of this ticket.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-25 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

I think just a few basic tests is all that's needed.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-25 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

In fact I had a few down minutes and put in a couple of multi-parameter tests 
and they seemed to work just fine. I'll add them to the patch.

They're fairly trivial, but at least start to exercise the option.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-25 Thread Dennis Gove (JIRA) 

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

Dennis Gove commented on SOLR-8467:
---

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

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

2016-04-25 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

I'll try to keep this up to date more often now that I've learned the 'git 
stash' and 'git stash pop' trick.

I'll also clean up the nocommits and the like sometime Real Soon Now.

Do note that there's some nonsense in the test cases to randomly switch back 
and forth between the Map and SolrParams c'tors in the classes. Mostly that's 
there to make sure the translation I made in the c'tors from Map to Solrparams 
gets exercised. That said, since there _are_ no more uses of the Map c'tor I 
could easily argue that it's not required that we keep exercising the 
deprecated (in this patch) Map c'tors, WDYT?

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-25 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

The fl handling you mention seems to be wrong. I'll give this a closer review.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-25 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-8467:
--

I think this ticket makes sense but I was shying away from it because it ends 
up touching such a large amount of code.

A couple things to consider before committing:

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.

2) Let's shoot for getting this into trunk following the 6.1 release. The 
reason behind this is that it touches enough stuff that it's likely to cause 
some headaches finishing some fairly big features in trunk which are still 
getting shaped up for the 6.1



> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-24 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

OK, I was able to beast the code for GraphExpressionTest and 
StreamExpressionTest and they seem OK. Well, I am getting a lot of 

"Unable to build keystore from file: null" errors, but I'm ignoring them so far.

I'm running full tests now, but I've attached a patch for what I currently 
have, nocommits and all. You'll see a lot of commented-out code in 
GatherNodeStream pending the resolution of my note from earlier today.

Meanwhile, are there objections to the approach? As I mentioned, I need to 
clean some things up before committing, and I think SOLR-8925 needs to be 
applied to 6x before this patch can go in

I'd like to keep from getting too far out of date, last time I let it languish 
I caused myself a lot of extra work as the underlying code is changing pretty 
rapidly, so comments appreciated.


> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2016-04-24 Thread Erick Erickson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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 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

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

2015-12-30 Thread Yonik Seeley (JIRA) 

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

Yonik Seeley commented on SOLR-8467:


bq. Patch that uses commons StringUtils. NOTE: This adds the dependency to 
SolrJ for commons.lang for the first time, any objections?
You could just use StrUtils.join instead?

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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

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

2015-12-30 Thread Erick Erickson (JIRA) 

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

Erick Erickson commented on SOLR-8467:
--

Didn't even know it existed. It compiles at least, running a test now.

Thanks! That's better than including a new dependency.

> CloudSolrStream and FacetStream should take a SolrParams object rather than a 
> Map 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 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