I think the most common way we do stuff like this is two have an API at both the "core" and "collection" levels, with the "collection" API being used to orchestrate N calls to the lower-level "core" API.
Using encryption as the example: the "core"-level API might manage the encryption of a single core. And then the "collection" level API would invoke the "core" API for each part of the collection, and do whatever other higher level logic is necessary (e.g. putting the collection into "read only" mode, sending messages to the overseer, etc.) This is a pretty common pattern among our collection operations. "Create collection" has a collection API to bootstrap the necessary ZK state and then uses a "core admin" API to create individual cores. "Backup" uses a collection API to put the collection into read-only mode, and then calls a "core admin" API for each core that needs to be backed up. etc. Hopefully that helps, unless I'm misunderstanding your question? Best, Jason On Wed, Nov 27, 2024 at 6:10 AM Bruno Roustant <bruno.roust...@gmail.com> wrote: > > Generally, where should go operations on a Collection? > At Collection admin level handler? > At Core level handler? > There are examples of both. > > I'm asking the question with the Solr encryption feature in mind (in > solr-sandbox). A client may want to encrypt all the indexes for a given > Collection. Which handler should receive the request? > A core level handler that would then distribute the request to all the > cores of the Collection across SolrCloud? Or a ClusterPlugin request > handler? > > Bruno --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
