I'm not entirely familiar with that "auto-created" configSet, but I think
I see what you mean. If your configuration is all within a collection
specific overlay you wouldn't even need to delete a config set, you would
just delete the collection (or possibly the overlay), so would entirely
avoid the loop in
https://github.com/apache/solr/blob/388101fc84140c0bdc50706637bcc5df11908ca6/solr/core/src/java/org/apache/solr/cloud/ConfigSetCmds.java#L186-L197
I can see an overlay being a useful general solution that adds value within
Solr and externally too
- stored under the collection
- included in backup and restore
- deleted when you delete the collection
- allows you to make collection specific modifications to override
common config - within reason - while still receiving updates to the common
parts.
- changing the entire content of a znode would be okay
- "hiding/deleting" a znode (or its children) from the common config
would be more complicated / harder to reason about, and probably isn't
generally necessary?
- an API that looks something like the existing configset API (with
read operations)
On Tue, 7 Jan 2025 at 17:20, David Smiley <dsmi...@apache.org> wrote:
> If we were to pursue my proposal, it'd mean that the auto-created configSet
> thing (creating a mutable configSet from an immutable template) could go
> away, which is a source of some complexity and scale concerns (loops all
> collections when certain configSets get deleted).
>
> On Tue, Jan 7, 2025 at 10:33 AM David Smiley <dsmi...@apache.org> wrote:
>
> > Where I work, we've used collection properties (collectionprops.json) to
> > store collection specific synonyms & query-elevation configuration. We
> > have custom plugins for those features to read/expire this information in
> > addition to implementing other custom requirements. It's somewhat of a
> > hack but it works while being rather lean implementation-wise as it uses
> an
> > existing mechanism.
> >
> > It'd be interesting if a collection could have a configset overlay as a
> > general feature and for modifying anything. It'd be stored inside a
> > collection's ZK node tree. SolrResourceLoader would overlay this with
> the
> > backing (ConfigSet) source.
> >
>
