Hi Andrea. I do like this idea. On Wed, Nov 5, 2025 at 6:58 PM Andrea Child <[email protected]> wrote:
> Hi Andrii, > > I agree it would be useful to support YAML config reuse. It would allow > users to have functionality-specific YAML config files and the finalized > YAML can piece together the desired features. > > Instead of ‘parent’ and ‘inheritance’ would it be better to support the > concept of ‘import’ or ‘include’? The difference being that a child config > would typically have a single parent and thus require a complex chain of > parents to obtain the configuration from multiple files. In contrast, the > idea of ‘import’ would support piecing together multiple config files > without any limitation to number of imported files. > > Thoughts? > > Andrea > > From: Andrii Lomakin <[email protected]> > Date: Wednesday, November 5, 2025 at 6:39 AM > To: [email protected] <[email protected]> > Subject: Proposal: YAML settings inehritance. > > Good day, colleagues. > > During the testing of our integration with Gremlin Server, I have noticed > one hurdle. > You should manually sync the configuration that you use for testing and > production. > > That leads to subtle mistakes in testing that undermine the quality of QA > routines. > I propose implementing inheritance of YAML settings, a widely used feature. > > It can be implemented using the > same com.fasterxml.jackson.databind.ObjectMapper#readerForUpdating > functionality. > > I propose adding the parentSettings property to the YAML file schema, which > should point to the initial settings file, either using the classpath: > prefix or directly to the file system path. > > It will also allow us to provide settings templates for different use cases > that should not be copied and pasted, but merely specified by users. > > WDYT? >
