[
https://issues.apache.org/jira/browse/SOLR-17256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885376#comment-17885376
]
Jason Gerlowski commented on SOLR-17256:
----------------------------------------
bq. Do we assume that the lambda doesn't need to really return anything?
In the current PoC the lambda is a Function, so the SolrClient method can
return any value that the lambda chooses to send back: probably a SolrResponse
in most cases, but users could have their lambda return a boolean, a field out
of the response, a Future for the async case, whatever.
bq. Should the lambda actually be a SolrRequest?
We could take in a SolrRequest instead of a lambda, but that feels a little
overly restrictive to me: it'd prevent users from using the many SolrClient
methods that don't take a SolrRequest, it'd prevent users from making multiple
requests with the derived client, it'd preclude us from making async calls with
the derived client, etc.
----
Not especially tied to any of those answers above, if there's a compelling
reason to go another way. But those answers reflect my rationale when I wrote
the PoC at least.
> Remove SolrRequest.getBasePath setBasePath
> ------------------------------------------
>
> Key: SOLR-17256
> URL: https://issues.apache.org/jira/browse/SOLR-17256
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Minor
> Labels: newdev, pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> SolrRequest has a getBasePath & setBasePath. The naming is poor; it's the
> URL base to the Solr node like "http://localhost:8983/solr";. It's only
> recognized by HttpSolrClient; LBSolrClient (used by CloudSolrClient) ignores
> it and will in fact mutate the passed in request to its liking, which is
> rather ugly because it means a request cannot be used concurrently if the
> user wants to. But moreover I think there's a conceptual discordance of
> placing this concept on SolrRequest given that some clients want to route
> requests to nodes *they* choose. I propose removing this from SolrRequest
> and instead adding a method specific to HttpSolrClient. Almost all existing
> usages of setBasePath immediately execute the request on an HttpSolrClient,
> so should be easy to change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
