[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17797318#comment-17797318
]
Jason Gerlowski commented on SOLR-17066:
----------------------------------------
I wanted to summarize what we have and have not yet done here, to make it
easier to resume work after the holiday.
We've now merged changes to 'main' which add "withDefaultCollection" to each
SolrClient Builder, so that SolrJ users don't need to stick the core/collection
in their base URLs. Obviously that's a far cry from our eventual goal to
deprecate/remove support entirely: users on 'main' (and branch_9x) can still
blithely ignore this new work and use the same core-based URLs they always
have.
To close the gap here, I think the remaining steps are:
# (branch_9x) Backport 0b2326d
# (main, branch_9x) Replace core URLs with the "withDefaultCollection" Builder
method in tests and server code
# (branch_9x) Update ref-guide/Javadocs to indicate deprecation of core URLs as
a SolrClient base. Maybe have SolrClient code log a warning if this is
detected?
# (main) Update ref-guide/Javadocs to indicate that SolrClients *only* accept
true base URLs (i.e. no core URLs)
> 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
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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]
