Yes exactly -- would be really cool! For example, imagine if the V2 API for this was here: /api/c/collection-name/config/files and you could HTTP PUT config/files/synonyms.txt And furthermore GET of files or listings would present the overlaid view.
This is all wishful thinking of course; it's some serious work to totally complete the vision. If you (or your colleagues, etc.) are interested in pursuing this, I could help define the work. On Wed, Jan 8, 2025 at 9:12 AM Colvin Cowie <colvin.cowie....@gmail.com> wrote: > 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. > > > > > >
