On 6/26/13, Branko Čibej <[email protected]> wrote: > On 26.06.2013 22:46, Apache Bloodhound wrote: >> What was the reasoning behind the decision that the product configs >> should >> be stored in the database instead of the .ini files? File configs would >> allow us to reuse trac functionality for detecting modification of >> configuration. > > Config files are evil. It's IMO a crazy idea to use config files when, > at the same time, you have a database available; because making atomic > changes on the filesystem and the database at the same time is hard and > error prone. > > And taking the long view, the existence of config files makes it much > harder to contemplate porting BH to a distributed platform (e.g., > GoogleAppEngine). > > I'd have expected, with all the pluggable architecture, that > configuration change listener would be just another interface and it > wouldn't matter where you actually store the config -- and that > trac_admin would trigger an event in tracd instead of the latter having > to poll the filesystem. >
hmmm ... two separate process though you'll always end up doing some kind of IPC between them . IMO there's no need to over-complicate the architecture with config listeners. As long as Configuration instances will be aware of last DB config everything is ok , even for Option(s) . What I'd recommend for DB config cache consistency is to have a shared memory IPC mechanism and a single datetime value tracking last config update (global or per-product) . If that value is newer that the one stored in Configuration instances then invalidate the cache . Nevertheless like I just said in previous message , I'm not sure of whether that will be enough . BTW , the similar issue related to wiki rename was detected running apache2 + PostgreSQL . trac-admin updates were visible in web UI after sending HUP signal to apache2 process . -- Regards, Olemis.
