Deeper nesting in database.yml ?

On a pretty regular basis now I’m writing apps that are connecting to multiple DBs. I’m finding that the existing “single DB per environment” structure of database.yml is cumbersome and trips me over fairly regularly.

I’m wondering if anyone else would welcome a patch whereby (optionally) you could provide a hash of connection specs within each of the different environment blocks? Something like this:

development:
default:
adapter: sqlite3
database: db/development.sqlite3
legacy:
adapter: mysql
database: foobar
username: foo
password:

production:
default:
adapter: mysql
database: my_app
username: myapp
password:
legacy:
adapter: mysql
database: foobar
hostname: legacy.server.local
username: foo
password:

?

I feel like it is more like an edge case. I don’t find myself doing this. But, many people might be doing this.

But, we already have 3 default database configurations now: development, test, and production. I really wonder how many people would like to have another nested layer of database configurations.

Rails already allows users to create multiple environments like cucumber other than the default three(development, test, production). If you want to do this, why don’t you just create another environment for your rails app?

For example:

development:
blah
blah
development_sqlite:
blah
blah
production:
blah
blah
production_legacy:
blah
blah

I might be wrong here. Feel free to correct me.

Thanks,
Siong.

I feel like it is more like an edge case. I don’t find myself doing this. But, many people might be doing this.

But, we already have 3 default database configurations now: development, test, and production. I really wonder how many people would like to have another nested layer of database configurations.

Rails already allows users to create multiple environments like cucumber other than the default three(development, test, production). If you want to do this, why don’t you just create another environment for your rails app?

Because your app won’t auto-select based on Rails.env. So you have to end up with hacks in your environments/*.rb files, or with manual establish_connection branches for all non-standard DBs.

This is precisely why I want what I want - because I want to have (for example):

class Legacy < ActiveRecord::Base
establish_connection(:legacy)
end

And then…

class Legacy::Foo < Legacy

blah

end

And I want that to have separate database.yml settings for the different environments, AND I want it to auto-select the right one based on Rails.env. I’m not saying that there aren’t already ways around this - like what I think you were proposing:

establish_connection( Rails.env + “_legacy” )

I’m just asking because it seems to be happening to me more and more in my real world apps, and I’ve been considering a gem or core patch, but the latter would only be worthwhile if it’s affecting a lot of others too.

Opss. Sorry. I guess I was wrong at my first assumption. So, what you actually want is the feature to manage to connect to multiple databases in one environment?

http://github.com/kovyrin/db-charmer ?

Hey,

When developing apps with datamapper it's not so uncommon to connect
to multiple repositories (per environment). Have a look at the "Sample
database.yml files" section in the README of

http://github.com/datamapper/dm-rails

for examples of single and multiple repository configurations used
when setting up datamapper. Also, fwiw, the latter format was the one
recognized by merb, which favored datamapper over AR.

I guess it would be nice tho, if the formats used for multirepo
database.yml would be roughly the same for activerecord and
datamapper.

cheers
snusnu

Nope, that feature already exists in vanilla Rails with the establish_connection method.

I see - so there they have a new key called 'repositories' where they store connections other than the default. That'd work too.

So, show of hands - worth adding to AR?