Jason Gerlowski created SOLR-17066:
--------------------------------------
Summary: Deprecate and remove core URLs in HttpSolrClient and
friends
Key: SOLR-17066
URL: https://issues.apache.org/jira/browse/SOLR-17066
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Reporter: Jason Gerlowski
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.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
