gerlowskija commented on code in PR #4799:
URL: https://github.com/apache/solr/pull/4799#discussion_r3855694024
##########
solr/solrj-streaming/src/java/org/apache/solr/client/solrj/io/stream/SolrStream.java:
##########
@@ -106,15 +106,16 @@ public SolrStream(String baseUrl, SolrParams params,
String core) {
/**
* @param baseUrl the Solr node's "base" URL (i.e. no core or collection in
the path
* @param core the name of the collection or core to query; must be hosted
at {@code baseUrl}
- * @param path the request handler path to query (e.g. "/export"). If not
provided, defaults to
- * "/select".
+ * @param path the request handler path to query (e.g. "/export"). If not
provided (i.e. {@code
+ * null}), the handler is instead resolved from a "qt" param embedded in
{@code params}, or
+ * defaults to "/select" if no such param is present.
* @param params query-parameters sent with the streaming request
*/
public SolrStream(String baseUrl, String core, String path, SolrParams
params) {
this.baseUrl = baseUrl;
this.core = core;
Review Comment:
I'd rather not unless you feel strongly? I've seen that sort of
string-manipulation logic be creaky/inflexible in other places in the past.
It's one of the reasons we're trying to move away from coreUrls.
You can think of all sorts of edge cases, e.g. what if a user is trying to
use SolrStream with a SolrClient that has a "default collection" set?
Also as I mentioned elsewhere, I'm planning to tackle SOLR-17995 in pretty
short order, so hopefully this'll be a moot point quite soon.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
