incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [BEP-0003] Request for comments : DB configuration vs ConfigParser
Date Mon, 07 Jan 2013 01:31:46 GMT
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?

I have no particular problem with the db only approach although I would 
be tempted to add a cli admin command to dump and load settings for a 
specified product.

Cheers,
     Gary

Mime
View raw message