[jira] [Commented] (SOLR-17066) Deprecate and remove core URLs in HttpSolrClient and friends

["David Smiley (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17995806#comment-17995806 ] 

David Smiley commented on SOLR-17066:
-------------------------------------

I was looking at the callers of {{SolrRequest.setPath}} and I see a number of places that include collections/cores, for example FacetStream and others.  I suppose this means there is follow-up to do?

bq. All of the clients are switched away from core URLs afaict. Though I wonder whether we shouldn't put some assertions into the SolrClient ctors as a way to flush out any usages that might be lingering out there, though maybe that's a different JIRA ticket...

Maybe we should link one.  _Maybe_ that'd be {{newdev}}.

> 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
>          Components: SolrJ
>            Reporter: Jason Gerlowski
>            Assignee: Jason Gerlowski
>            Priority: Major
>             Fix For: 9.5
>
>          Time Spent: 14h 10m
>  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: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org