[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784048#comment-17784048
]
Jason Gerlowski commented on SOLR-17066:
----------------------------------------
Yes, definitely - I actually called out SOLR-10466 in the description above; I
figured we might choose to resume that discussion here.
If I had to summarize the consensus and key takeaways in SOLR-10466, they'd be:
# *Strong consensus around SolrClient immutability* - a Builder method is much
preferable to a setter on the client itself.
# *Agreement that "defaultCollection" is largely there as a "convenience"*.
# *Overall dissatisfaction with SolrJ's collection handling*
** It's too complicated - collections/cores can be specified in at least three
places: on the SolrRequest itself, as a client-wide default, and as a method
param for various SolrClient methods.
** SolrClient suffers a lot of interface-bloat from the method-overloads that
take in a collection.
** Specifying a "collection" on a client breaks an otherwise clean
division-of-responsibility between SolrClient and SolrRequest.
# *Interest but no consensus on how to improve collection handling* Should we
eliminate all of the collection-including SolrClient methods? Should we create
a delegating wrapper SolrClient to inject a default collection as necessary?
Should we move all collection-specifying onto SolrRequest? A lot of ideas,
many of which are not mutually exclusive, but no clear agreement on how to move
forward.
----
The way I look at this ticket, it doesn't solve the collection-handling
questions that SOLR-10466 raised. But it does tackle an important
prerequisite. None of the approaches mentioned in (4) above will work if we're
still allowing users to sneak collection/core names into base URLs.
Eric got consensus around the "withDefaultCollection" Builder method on
SOLR-10466, so adding that to other Builders made sense as a way to get rid of
these collection-based URLs. But I'm open to other ideas and I definitely
don't want it to block other progress around how collections get specified in
SolrJ.
> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
