Reputation: 128
I'm working on a Rails app with a few collaborators and we decided to begin using separate database.yml files for some time until we can a configuration that works for all of us.
After adding database.yml to the .gitignore file and pushing a version without it, I realized that this would likely prevent the Heroku app from running.
My confusion is that the deployment was successful and the database.yml file was not needed. Why is this? Is our old database.yml file cached?
Upvotes: 0
Views: 487
Reputation: 102046
Ah yes the old db config developer war.
Heroku actually uses the solution to this issue - Rails merges the database configuration from database.yml
with a hash created from parsing ENV["DATABASE_URL"]
. The ENV var takes precedence over the file based configuration.
When you first push a Rails app, Heroku automatically attaches a Postgres addon and sets ENV["DATABASE_URL"]
and presto your app magically connects to the database.
Even if you add complete nonsense settings like setting the database name in database.yml
the ENV var still wins.
How can this solve our developer war?
Do the opposite of what you are currently doing. Strip everything except the bare minimum required to run the application out of database.yml
and check it back into version control.
Developers can use direnv
or one of the many tools available to set ENV[DATABASE_URL]
to customize the settings while database.yml
should be left untouched unless you actually need to tweak the db.
Upvotes: 1
Reputation: 5426
This is actually the expected behavior. For more details see: https://devcenter.heroku.com/articles/rails-database-connection-behavior
Which boils down to (for Rails 4.1+):
While the default connection information will be pulled from DATABASE_URL, any additional configuration options in your config/database.yml will be merged in.
Heroku will always use DATABASE_URL and merge the rest from database.yml to the config contained in that url.
Upvotes: 1