[
https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-18446:
--------------------------------
Description:
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.
was:
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's acknowledged and out-of-scope that there are parameters like "shards"
affecting how a handler (e.g. SearchHandler) dispatch distributed work.
> 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]
