[
https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116256#comment-18116256
]
Jan Høydahl commented on SOLR-18446:
------------------------------------
The "collection" parameter is documented here
[https://solr.apache.org/guide/solr/latest/deployment-guide/solrcloud-distributed-requests.html#collection-parameter]
What seems to happen in the code (HttpSolrCall) is that "collection" url param
takes precedence if specified.
But if not specified, it will also allow a comma separated list of collections
in the URL, e.g.
{code:java}
http://localhost:8983/solr/collection1,collection2/select?q=*:* {code}
Or if the URL path was an alias, it will be expanded to a list of collections.
I.e. three possible sources of collection list.
I support getting rid of the "collection" URL parameter. But should we still
support the comma separated path element? It's also the "opensearch" way of ad
hoc querying multiple indices. I guess there may in some cases be ambiguity of
which of "collection1" or "collection2" should be used as lookup key for
various decisions about the request, but that ambiguity will also exist for
alias with multiple collections as destination.
> 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]
