[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18003801#comment-18003801
]
David Smiley commented on SOLR-17066:
-------------------------------------
I wish for a constructor with its inherent class hierarchy alone to hold
essential elements to characterize the request.
GenericSolrRequest.setRequiresCollection is sad to me because the collection
aspect is so fundamental to the request that, IMO, it should be in either in
the constructor or in effect the same by using another subclass to make this
very prominent. If there was a GenericCollectionSolrRequest, this would be
better. I don't love the name of the abstract class
"CollectionRequiringSolrRequest" because of the word "Requiring" in there; it's
very superfluous, and makes the name more verbose. So I'm tempted to create a
GenericCollectionSolrRequest. Ultimately make
GenericCollectionSolrRequest.requiresCollection field non-existent, and thus no
setter.
Similarly, I think of the path as so fundamental to the request that it belongs
in the constructor, not to be set afterwards via setPath.
> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
