On Sat, Sep 10, 2011 at 12:29 AM, Trevor Leffler <[email protected]> wrote:
> Trevor Leffler wrote: > >> Rob Kinyon wrote: >> >>> On Fri, Sep 9, 2011 at 11:30, Alan Humphrey <[email protected]> >>> wrote: >>> >>>> Hi – >>>> >>>> I’m wondering how people are handling connecting to different databases, >>>> e.g. dev vs. test vs. production. Is there a technique that’s >>>> considered >>>> “best practice”? >>>> >>> >>> Configuration files are good things. Just swap in the right config >>> file for a given environment. >>> >> Yes, this isn't really DBIC specific, but I wrote a config system that merges together different config files into a final hash that can be used by a number of tools -- including cron jobs and our Catalyst-based apps. We set an operation mode (e.g. production, staging, testing, dev) in the environment and the config system merges config.yml, conf/$mode.yml, /etc/$app/$mode.yml, and $HOME/local_$app.yml. That way, config.yml has the bulk of the config, then something like production.yml just changes the few settings needed for production. We can inherit, too. For example, staging.yml can say "inherit: production.yml" and then staging can override setting set for production. The /etc/ fies is to allow the site operators to override config, if needed, and the $HOME config allows developers to override config on their development machine. It's actually a bit more convoluted than that, because each config file can have sections specific to a given operating mode. -- Bill Moseley [email protected]
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
