[Config-loader] Scope of the project

[Clinton Gormley]

> 
> The loader finds:
> 1.  /path/to/config/my_appl.cnf 
> 
> 2.  /path/to/config/my_appl_local.cnf
> 
> The loader loads  first my_appl.cnf, then my_appl_local.cnf, with the
> latter overwriting the former.
> 
> The following could work too:
> 1.  /path/to/config/my_appl.cnf 
> 2.  /path/to/config/my_appl_local.yml

Gotcha

> > Right now, I'm thinking that local overrides and such should be the
> > responsibility of the source. What if
> > the source is a database? Path-style localization doesn't make much
> > sense there.

Well, I think it's actually about the load_method (or something like
that), so you could have 

   load_method => 'overwrite'
   load_method => 'merge'

The 'source' loads the new data. The controlling process should know at
which point in the hash tree we're inserting the new data, and then, if
the load_method is 'overwrite', it just does:

     $config->{$insert_point} = $new_config

but if it's 'merge' then it dives into $new_config looking for single
keys to override.

If the source is a DB, then it could return a flat data structure which
can only be inserted into the config hash at the specified point, or (as
per my previous example), it could return a hash with keys like
'app.db.slave.hostname' which can then be used to override specific
nested keys.

That behaviour would obviously be controlled by a switch.

does that make sense to you?

clint 
> 
> Rob
> _______________________________________________
> Config-loader mailing list
> Config-loader at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/config-loader