Paul Lynch wrote: > I was actually talking about updating an existing production > database. In such a case, the migrations which would be run would be > just the ones between the previous release and the current one.
This should not cause problems in most cases. You mentioned that some of the problems involved application data; either that sort of thing should be removed from migrations or the migrations should provide for it. (If you have more concrete examples, I'll try to see how I'd handle them.) If by "application data" you mean things like tables of country codes or shipping rates, these absolutely do not belong in migrations. Try something like seed_fu. Basically, migrations should provide all the changes necessary to get the DB from one consistent state to the next. If you are having problems with migrations, then they probably do not adhere to this guideline. > > I have not tried your suggestion of rake db:schema:load but, judging > by the contents of schema.rb, this would drop all of the tables and > recreate them. We would lose both our application data and our user > data. Right. > Perhaps I misunderstood how you were thinking to use that? You didn't misunderstand; I thought you were talking about a different situation. Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org -- 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-talk@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 -~----------~----~----~----~------~----~------~--~---
