On 13 August 2010 18:05, Fearless Fool <[email protected]> wrote: > [...] > I have *two* databases: the 'external' one holds static data -- it never > changes as a result of my application. The 'regular' database > (dbtest_development, dbtest_test, or dbtest_production) holds data that > does change as a result of running the application. > > I need to split my data between the external and the regular databasen. > > I've thought about how rake db:migrate works -- it modifies a database, > then asks the database to reveal its new structure to build a new > schema.rb. Given that, it doesn't have enough information to know which > tables belong in the regular database and which belong in the external > database. In short, db:migrate can only work on one database at a time. > (Am I right?) > > BUt your reply gave me an idea. I could define a rake task that > essentially calls: > rake db:migrate > rake db:migrate RAILS_ENV=external > thus always keeps a parallel structure between the two databases. It's > a little clunky, because I would only be using one of the tables in the > external database, but that shouldn't really matter.
I suppose you could test RAILS_ENV in the migration rb file and only do the migration if it is appropriate for the env specified. Then rake db:migrate RAILS_ENV=development would apply relevant migrations to the development db rake db:migrate RAILS_ENV=external would apply relevant migrations to the external db. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
