Marnen Laibow-Koser wrote: > That seems like a terrible idea. It would put a lot of unnecessary > crap in both databases.
Just a clarification: my heavy-handed approach would create parallel table structures in both databases, but only the relevant tables would get populated with any data. [That is, unless I used my migration files to create fixture data, which I would never DREAM of doing! ;) ] Colin Law (Guest) wrote: > 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. Heh -- that could be pretty cool -- I'd have to think a bit deeper on this approach, as we wouldn't want migrate's state to get confused (since it is written in the database itself). Marnen Laibow-Koser wrote: > I seem also to recall some talk of using establish_connection in the > migration files themselves. Will that work, or am I misremembering? In my first post in this thread, you can see that's what I attempted without success. But Colin's approach (above) has promise. If you find a pointer to a working recipe, I'd be in your debt. I'll continue to noodle on Colin's approach and report back. Thanks, all! - ff -- Posted via http://www.ruby-forum.com/. -- 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 rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
