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:
?
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
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. On Thu, Mar 4, 2010 at 7:02 PM, Jason King <smathy.werp@gmail.com> wrote:> 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: > > > > ? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mar 4, 2010, at 5:39 PM, Teng Siong Ong wrote:> 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 ? On Thu, Mar 4, 2010 at 7:50 PM, Jason King <smathy.werp@gmail.com> wrote:> On Mar 4, 2010, at 5:39 PM, Teng Siong Ong wrote: > > 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. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 On Fri, Mar 5, 2010 at 03:03, Teng Siong Ong <siong1987@gmail.com> wrote:> 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 ? > > On Thu, Mar 4, 2010 at 7:50 PM, Jason King <smathy.werp@gmail.com> wrote: >> >> On Mar 4, 2010, at 5:39 PM, Teng Siong Ong wrote: >> >> 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. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mar 4, 2010, at 6:03 PM, Teng Siong Ong wrote:> 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?Nope, that feature already exists in vanilla Rails with the establish_connection method. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.