Description
Currently, URL-driven SolrClients can consume a base URL that either ends in an API-version specific path ("/solr" for v1 APIs, "/api" for v2), or in the full path to a specific core or collection ("/solr/techproducts").
The latter option causes a number of problems in practice. It prevents the client from being used for any "admin" requests or for requests to other cores or collections. (Short of running a regex on SolrClient.getBaseURL, it's hard to even tell which of these restrictions a given client might have.) And lastly, specifying such core/collection URL makes it tough mix and match v1 and v2 API requests within the same client (see SOLR-17044).
We should give SolrJ users some similar way to default collection/cores without any of these downsides. One approach would be to extend the withDefaultCollection pattern currently established in CloudHttp2SolrClient.Builder.
(IMO we should also revisit the division of responsibilities between SolrClient and SolrRequest implementations - maybe clients shouldn't, directly at least, be holding on to request-specific settings like the core/collection at all. But that's a much larger concern that we might not want to wade into here. See SOLR-10466 for more on this topic.)
Attachments
Issue Links
- blocks
-
SOLR-17044 Improve API path specifying in SolrJ
- Open
- causes
-
SOLR-17234 LBHttp2SolrClient does not skip "zombie" endpoints
- Resolved
- duplicates
-
SOLR-16563 Http2SolrClient should have a defaultCollection setting
- Resolved
- is related to
-
SOLR-10466 setDefaultCollection should be deprecated in favor of SolrClientBuilder methods
- Closed
- links to