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

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

Lots of tests were broken because of this!  I use {{git bisect}} to determine 
the failures lead to this commit (for PR 2231), at least on branch_9x.

> 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
>            Priority: Major
>          Time Spent: 9h 20m
>  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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to