Jason said: > There's not currently a "shard-level" path for querying, but other > APIs currently exist at the > "/collections/someColl/shards/someShardName" path, so it's only a > small leap to offering querying there. >
So Jersey/OpenAPI will have no problem with all the core handlers being addressable at two levels; with and without the shard? If so then this URL structure makes most people happiest. I don't love that "shards" would exist in the same namespace as handlers in solrconfig, thus making it impossible to have a <requestHandler name="/shards"> but this is very minor. On Tue, Jan 14, 2025 at 8:20 AM Pierre Salagnac <pierre.salag...@gmail.com> wrote: > The issue with v1 API is ambiguity, and I'm concerned matrix parameters > won't be sufficient to resolve ambiguities. In the case of > /solr/my-id;r=core1/select , we still don't know whether my-id is a shard > or a collection. Both are conceptually valid. > In my proposal, "my-id" would always be a collection; no exceptions / ambiguity. > Or can matrix parameters be required? I think such parameters are in > essence optional, but I'm definitely not an expert here. > Optional. ----- Any way, for V1, CloudSolrClient sends a parameter like this: _stateVer_=collection1:3 It's used for distributed ClusterState cache invalidation by CloudSolrClient.[1]. It's a list of collections and their versions (consider that aliases may point to multiple collections). For V1 HttpSolrCall could consider this parameter in resolving the ambiguity of the path. It's maybe a hack, depending on your point of view. If that parameter is supplied, and if the path isn't a collection name then it can be resolved against the cores of the collection(s) of stateVer. Ultimately SOLR-17568 (main-only) could be partially reverted and then modified as I propose in this discussion. [1]: BTW I am working on an exciting proposal on coordinated ClusterState cache invalidation holistically.
