[
https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116371#comment-18116371
]
David Smiley commented on SOLR-18446:
-------------------------------------
Somewhat related is an idea I've had but haven't discussed much. I'll share it
here, even though it's very likely it's own discussion/JIRA. The idea is that
the URL path establishes the scope of what should be searched, not something
lesser (unless of course the URL is augmented to support that, as I do want and
proposed). In other words, given collection "foo", a request to
{{/solr/foo/select}} is scoped to the foo collection. It might be routed to
any core to serve the request but that core will understand the intended scope
sourced from the URL (that's new; not _quite_ how it works today). What I
rather dislike, is that today you can send a request to
{{/solr/foo_shard1_replicaWhatever}} and that specific replica is aware it's in
SolrCloud and will understand the scope to be the entire collection. I'm a
guilty party in code reviewing / approving a colleague enhancing
CloudSolrClient to route an updates to a specific named replica on a node
instead of using the collection name. I regret that. But the server side has
worked this way beforehand and, I don't like it. I'd like to change that for
Solr 11.
> Remove "collection" param routing support in HttpSolrCall
> ---------------------------------------------------------
>
> Key: SOLR-18446
> URL: https://issues.apache.org/jira/browse/SOLR-18446
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Reporter: David Smiley
> Priority: Blocker
>
> The URL path alone should govern which collection receives a
> collection-scoped request. Node level APIs (e.g. admin) don't count here.
> Consequently, the "collection" parameter should be removed or altered in
> semantics from the present day.
> It'd be harmless if the collection param were to assist in disambiguating a
> core name in the path, if we want that, as that prevents a 404.
> It'd be harmless if the collection param disambiguated multiple possibilities
> if the path implied more than one (i.e. was an alias to multiple collections
> or was comma delimited).
> It's acknowledged and out-of-scope that there are parameters like "shards"
> affecting how a handler (e.g. SearchHandler) dispatch distributed work. The
> scope of the current ticket is basically HttpSolrCall resolving to a "core"
> locally or remotely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
