[
https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116384#comment-18116384
]
Jan Høydahl commented on SOLR-18446:
------------------------------------
Perhaps we should feed this entire discussion along with our current path
schemes into some AI and have it reason about a meaningful consistent pattern
that is logical and still preserves our need to address shards or replicas. As
an example, other APIs out there use special underscore prefix for path
elements to say "here is a special system controlled name space" and the matrix
thing is another way to tag things. Would be great to land a structure that can
be clearly documented for future API evolution the next 10 years.
> 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]
