Repository navigation
SOLR-18446: Keep collection routing path-scoped in HttpSolrCall - #5202
nick-boss-tech wants to merge 2 commits into
Conversation
github-actions
Bot
added
documentation
| String collectionStr = queryParams.get(COLLECTION_PROP, origCorename); | ||
| collectionsList = | ||
| resolveCollectionListOrAlias(collectionStr); // &collection= takes precedence | ||
| String collectionStr = origCorename; |
There was a problem hiding this comment.
I suppose teh collectionStr sort of better conveys the werid remapping of what looks like a core to a collection.
I wonder, is there a better name than origCorename that would somehow convey that we cover both core and collection? Maybe I have seen coreOrCollection ?
There was a problem hiding this comment.
🤖 AI text below 🤖 (reviewed by Nick Shanin)
The rename to coreOrCollection is in 1c0a942ff8. It covers the field in HttpSolrCall and its uses in V2HttpCall, with no behavior change.
| SolrQuery query = new SolrQuery("*:*"); | ||
| query.set("collection", "collection2,collection3"); | ||
| long found = clients.get(0).query(query).getResults().getNumFound(); | ||
| long found = clients.get(0).query("collection2,collection3", query).getResults().getNumFound(); |
There was a problem hiding this comment.
interesting, so I can just put in the path multiple collections comma delimited... how not restful is that? or is that okay? If it was a concept we supported, well, there are bunch of APIs that might benefit by "comma dellimited list in a path param"... s
There was a problem hiding this comment.
🤖 AI text below 🤖 (reviewed by Nick Shanin)
Yes, v1 distributed queries already support comma-separated collections or an alias in the path. Jan describes both on SOLR-18446, and David confirms that comma-delimited support came from the time-routed-alias work and should stay. This PR keeps that support; the collection parameter can narrow the path's collections but cannot override them.
| The collection named in the URL path governs which collections a query runs against. | ||
| To query several collections at once, name them in the path, as a comma-separated list or through an alias; the features of Solr which work in a distributed manner will work across those collections. | ||
|
|
||
| The `collection` parameter can only narrow the set named in the path. |
There was a problem hiding this comment.
if we are dropping the use of the collection parameter? Which I think it what we ant to be doing right? Then we don't need to document it or show it.
Or, are we deprecating the "collection" parameter and changing it's behavior?
There was a problem hiding this comment.
🤖 AI text below 🤖 (reviewed by Nick Shanin)
Neither dropped nor deprecated. The parameter no longer selects collections on its own; it can only narrow the set named in the path. The page now documents that narrower role, and the example is corrected to show narrowing: /solr/collection1,collection2,collection3/select?collection=collection2.
| A node started this way asks the Overseer to re-run its node prioritization, so a preferred node takes over without waiting for the current Overseer to restart. | ||
| Note that node roles are fixed for the lifetime of a node: unlike `ADDROLE`, they cannot be changed on a running node. | ||
|
|
||
| === `collection` Parameter No Longer Routes Requests |
There was a problem hiding this comment.
so I guess I am slightly unclear, it feels to me like the collection parameter is no longer needed?
There was a problem hiding this comment.
🤖 AI text below 🤖 (reviewed by Nick Shanin)
It is optional, but still useful for narrowing a v1 request whose path names several collections or an alias. For example, /solr/collection1,collection2/select?collection=collection2 selects only collection2. The entry means the parameter can no longer override the path, rather than that it has been removed.
|
Put some comments in, but I htink I need @dsmiley to weigh in.... |
🤖 AI text below 🤖 (posted on behalf of Nick Shanin)
https://issues.apache.org/jira/browse/SOLR-18446
What happens today
When a request carries a
collectionparameter that disagrees with the collection named in the URL path, HttpSolrCall routes by the parameter, so the request can be served by a collection it was not addressed to.HttpSolrCall at the base resolves the request's collection with the
collectionparameter taking precedence over the path. The ticket states the rule this violates: the URL path alone should govern which collection receives a collection-scoped request.What this change does
The URL path decides the collection, on the v1 and the V2 entry paths alike; the
collectionparameter no longer overrides the path the request was sent to.HttpSolrCall.java takes the collection from the path, and V2HttpCall.java now resolves the collection from its path segment instead of the parameter. HttpSolrCallCloudTest covers the v1 disagreement case, the narrowing case, and the V2 disagreement case. Four existing tests that relied on the parameter winning (BasicDistributedZkTest, TestDistribIDF, RuleBasedAuthorizationCoreCollectionTest, DistributedQueryComponentOptimizationTest) now put their collections in the path, and AliasIntegrationTest keeps a case where a CloudSolrClient carries the collection only as a parameter, which the client moves into the path. The Ref Guide's distributed-requests page now describes the parameter as narrowing the path, and the Solr 11 major-changes page records the removal. Eleven files change, including the changelog entry.
Proof
The new V2 coverage failed before its fix and passes at this head; the checks below ran on this exact tree, verified 2026-10-22.
expected:<[collection1]> but was:<[collection2]>(the parameter winning on the V2 path); the other four HttpSolrCallCloudTest tests passed.Limits
Requests whose parameter matches their path route as before. Three cases change: a parameter that disagrees with the path, a request with no collection in the path, and a multi-collection path with a non-matching parameter.
collectionparameter will now be routed by the path./solr/select?collection=c1, now returns 404 instead of routing by the parameter.Changelog: changelog/unreleased/SOLR-18446-path-controls-collection-routing.yml
AI-generated description. Nick Shanin directed the work and takes responsibility for this contribution.