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

["Jan Høydahl (Jira)" <ji...@apache.org>]

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

Jan Høydahl commented on SOLR-17066:
------------------------------------

There were some discussions in SOLR-10466 regarding defaultCollection, you may want to revisit.

CC: [~dsmiley] [~epugh] 

> 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: 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