bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [BEP-0003] Request for comments : DB configuration vs ConfigParser
Date Mon, 07 Jan 2013 04:51:34 GMT
On 1/6/13, Gary Martin <> 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 ?



Blog ES:
Blog EN:

Featured article:

View raw message