On 1/6/13, Gary Martin <[email protected]> wrote: > On 04/01/13 23:11, Olemis Lang wrote: >> While working on #115 I've tried to keep new config objects interface >> identical to Trac's . Nonetheless the later have two levels of caching >> : >> >> 1. `_cache` instance method >> 2. Mapping object(s) used under the hood by ConfigParser instance >> used to load INI file (e.g. trac.ini) >> >> This means that write operations on configuration files only touch (2) >> in first place and changes are not persisted until after save() method >> is invoked . >> >> The circumstances for multi-product configuration are a bit different >> considering the fact that settings will be stored in the DB . So in >> that case I'm considering the possibility of commiting changes right >> away to the DB rather than having a second-level cache since the later >> approach will make things easier afaics . Nonetheless that will break >> somehow the contract of `trac.config.Configuration` type , ... >> >> ... so I'd like to know beforehand if anybody has anything to say >> about that subject . Comments ? Objections ? >> > > I am interested in the scope of configuration that we are aiming to > achieve here. Are we only going to be considering a limited set of > options so that per-product settings cannot cause conflicts or are we > likely to go much further than this? >
The initial solution I'm writing considers product-specific configuration inherits global configuration , working just like current [inherit] section. I know that configuration access MUST be restricted under certain circumstances . This subject is related to a much broader discussion (we have neither started yet , nor documented in BEP 3) consisting of a new role we need to figure out how to make it fit into the new architecture . I'm talking of `PRODUCT_ADMIN` vs `TRAC_ADMIN` . Access rules for configuration options are essential to make that distinction . Nonetheless , dumb inheritance is a quite good initial step forward towards a more robust solution , so I request this to become an enhancement afterwards (i.e. new ticket spawned from #115 ;) > I have no particular problem with the db only approach I've been thinking that it shouldn't . Initially I thought of product-<prefix>.ini file in environment's config subfolder and I recall brane asking for the DB be at least the one offered by default . Support for different settings repositories is definitely needed . However it should be added later by leveraging initial (default) DB solution to fit into a more generic scenario with extension points , etc ... Therefore it deserves a separate ticket spawned from #115 . > although I would > be tempted to add a cli admin command to dump and load settings for a > specified product. > +1 , seems very reasonable to me . I'd rather prefer a new ticket for that feature . What d'u think ? -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
