There are a couple advantages to having a lot of the config info in a flat text file:
First, it is easy to review and compare the configurations of two projects as everything is in a human-readable format (and 'diff' is your friend). Second, and probably more important, is to make use of the [inherit] directive to centralize the management of several trac instances on a single server. I don't know about others, but I run about a dozen trac instances on a single server, and about 90% of the configuration is in a common inherited config file. It really makes setting up a new instance simpler (especially when we need to make a site-wide configuration change). That said, philosophically I agree with storing everything in the db. I don't see why there couldn't be a similar directive to [inherit] in an entirely db-based configuration system (maybe even inheriting off a common db URL to supported distributed servers). Further, I am sure that if someone cared enough about investigating and comparing configurations, they would contribute a utility program to parse the db info out to some human-readable equivalent (maybe even back to the original ini format). This could even be a plugin to trac-admin. On Sat, 2009-03-07 at 09:02 -0800, Evan Dower wrote: > This brings up something that has been kind of confusing for me. Why > do we keep so much information in the environment config file? It > seems to me like it should go in the DB. In fact, I think the only > thing that should go in the config file is what's necessary to locate > the DB. That would make it so you can run multiple front-ends that > talk to the same DB, allowing you to scale more easily. Of course, I > realize that if you're using Subversion, you have to be on the repo > box anyway, but at least with 1.5 you can set up repo replicas to get > around that. Is there philosophical opposition to this, or has it > simply not been done? > > On Fri, Mar 6, 2009 at 5:22 PM, Remy Blank <[email protected]> wrote: > > Shane Caraveo wrote: > >> memcached should be considered while looking at reworking the cache > >> system. > > > > I assume you are talking about: > > > > http://trac.edgewall.org/wiki/TracDev/Proposals/CacheInvalidation > > > > This is a very specific issue with in-process caches that are already > > present at various locations in Trac (ticket fields, wiki page names, > > InterMapTxt and CachedRepository.youngest_rev for example). This data is > > read from the database and kept in memory to avoid hitting the database > > if not necessary. The trouble is, when one process modifies the data in > > the database, other processes don't know that their cached data is not > > valid anymore. > > > > The current solution is to force an environment reload, which is quite > > inefficient. The goal of the proposal is to find a way of notifying > > processes that some cache has become invalid, with a finer granularity > > than "reload everything". > > > > Memcached definitely looks interesting, but I don't think it is the > > right tool to solve this particular issue. Introducing a new external > > dependency for the only purpose of notifying processes that some of > > their data has become invalid seems quite overkill. > > > > -- Remy > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
