Deeper nesting in database.yml ?

rubyonrails-core
1

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:

?

2

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.

3

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.

4

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 ?

5

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

6

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

7

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?