[
https://issues.apache.org/jira/browse/SOLR-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131208#comment-18131208
]
Nick Shanin commented on SOLR-18470:
------------------------------------
🤖 _AI text below_ 🤖 _(reviewed by Nick Shanin)_
[~dsmiley], [PR #5202|https://github.com/apache/solr/pull/5202] covers
SOLR-18446 only: the {{collection}} parameter can no longer override the path
on distributed requests. It deliberately does not attempt this ticket.
Taking your advice on the dev list to line up a reviewer before starting work:
before building anything here, I wanted to check whether this is a direction
you want taken up, and whether you would be willing to review it.
The plan I have in mind:
* Add path scope as a first-class characteristic of {{SolrQueryRequest}}: the
collection or core named in the URL path, with an alias or comma-separated list
resolved to its set of collections where that applies.
* Let each handler judge whether it can honor that scope; a collection handler
that cannot should return HTTP 400 rather than act on the core or node that
happens to serve the request.
* Start with collection handlers. Treat the core-path behavior, including
{{SearchHandler}} searching the whole collection in SolrCloud mode, as a
separate slice if you agree it is too much for one change.
* Parameters such as {{shards}} may narrow the path scope, never expand it.
Three questions: is that first slice the right size, should the core path be in
or out of it, and is there anything in the description you would now narrow or
drop?
> Limit collection handlers' scope to URL path
> --------------------------------------------
>
> Key: SOLR-18470
> URL: https://issues.apache.org/jira/browse/SOLR-18470
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
>
> The URL path should govern the data scope of a collection/core handler
> request. Inside Solr, this should be a first class SolrQueryRequest
> characteristic. It doesn't exist today; getPath() isn't it.
> A request to _collection_ "collection1" at /solr/collection1/handler implies
> that the scope is to the collection, not to whatever core handles it. If
> that's nonsensical for a given handler (only the handler itself can judge
> this) and no other parameter further specifies a specific core, then the
> client should get an HTTP 400. This may be a change to perhaps certain admin
> handlers that operate on the core/node serving the request.
> Note the URL path may be an alias to multiple collections or a comma
> separated list, and thus the resolved result is a set of collections.
> Perhaps only SearchHandler can reasonably respond to multi-collection, and
> /update in certain cases (e.g. time routed aliases).
> It's acceptable for additional parameters, e.g. "shards" to imply a _subset_
> of the path scope.
> The principle idea of this issue should apply to a core in the path... but it
> may be too much scope: A request to a _core_ "core1" at /solr/core1/handler
> implies that the scope is to the core. I think all core handlers can
> suitably interpret this. This is a change to how SearchHandler works in
> SolrCloud mode, which will search the whole collection. Perhaps /update
> should fail if an update doesn't belong locally -- on princiiple but
> admittedly maybe not worth doing.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
