@Lathi.net: config/database.yml goodness for teams

config/database.yml goodness for teams

Doug — Thu, 02 Mar 2006 09:00:00 -0600

If you’re a one hacker shop doing Rails development it’s no big deal to store all your database usernames and passwords in config/database.yml. When you’re part of a team all hacking on the same code it becomes a little more complicated. This is my humble solution that I’m sure dozens of folks have already thought of.

This is the ugliness of the default generated config/database.yml:

development:
  adapter: mysql
  database: rails_development
  username: root
  password: my super secret password

So let’s say we have one master config/database.yml checked into svn and each developer modifies the file with their own username and password. Now we’re stuck with the risk of each developer accidentally checking in their working modification of that file. Also, do you really want your production database username and password stored in svn?

This morning I had an epiphany. Thanks to Rails 1.0 we can embed ERB into the config/database.yml. Usually I only think of doing things like outputting environment variables and the like. It occurred to me this morning you can put arbitrary Ruby inside the config/database.yml.

First we have to restructure the yaml:

login: &login
  username: defaultuser
  password: defaultpassword

development:
  adapter: mysql
  host: localhost
  database: foo_development
  <<: *login

I learned that syntax from the Typo guys. It basically lets you name blocks and then reuse them later in the yaml file. You probably see where I’m going with this…

login: &login
  username: defaultuser
  password: defaultpassword

<%= file = File.join(RAILS_ROOT, "config", "dblogin.yml")
    IO.read(file) if File.exist?(file) %>

development:
  adapter: mysql
  host: localhost
  database: foo_development
  <<: *login

What this will do is insert the contents of config/dblogin.yml if it exists. This allows each developer to have a separate file in their working dir with their personal db login information. Further, you can svn propedit svn:ignore config to tell svn not to complain about the unknown file dblogin.yml.

"config/database.yml goodness for teams" by gothic wedding dress

Thu, 29 Jun 2006 06:12:57 -0500

Yes, it’s true

"config/database.yml goodness for teams" by choose fashion jewelry

Thu, 29 Jun 2006 06:12:38 -0500

Choose here

"config/database.yml goodness for teams" by womens dress suit

Mon, 26 Jun 2006 18:56:38 -0500

All about women dresses

"config/database.yml goodness for teams" by free music ringtone

Thu, 15 Jun 2006 08:54:51 -0500

I’ll be back!

"config/database.yml goodness for teams" by Doug

Tue, 07 Mar 2006 06:40:57 -0600

Good advice, Mark! Thanks for the reminder.

"config/database.yml goodness for teams" by Mark Mascolino

Mon, 06 Mar 2006 21:37:43 -0600

Neat trick. I think it should go without saying but you should also check in a nice config/dblogin.yml.sample to svn to show an example of what needs to be filled out. I’ve always found that to be handy when picking up a codebase after not using it for awhile.

"config/database.yml goodness for teams" by Doug

Mon, 06 Mar 2006 07:35:02 -0600

Two reasons:

First, when you set RAILS_ENV to some environment you also have to have a corresponding config/environments/foo.rb file. For multiple developers that’d probably end up as a symlink to config/environments/development.rb. That’s look like clutter.

Second, I wouldn’t really want my own username and password stored in the config/database.yml either. What your suggesting is that everyone put their own personal db username and password in one file and then check that into svn.

With my solution the config/dblogin.yml file is local to the developer’s working directory. It doesn’t require global visibility at all.

"config/database.yml goodness for teams" by Ed Sumerfield

Sun, 05 Mar 2006 14:39:02 -0600

Why wouldn’t you add additional environments to database.yml?

dev_doug: ... dev_ed: ...

Then I just need to set the RAILS_ENV variable to choose the one you want.