I see sublime elegance in having the DB store the DDL to revert migrations. I haven't worked with large teams in years, but I see the dilemma Steven is addressing:
The common DB is at Rev N User (or branch) A migrates common DB up to Rev N + 1 User (or branch) B is "checked out" and expects common DB to be at Rev N. Result: User/branch B is stuck: code to rollback the DB to Rev N exists only in User/branch A. Sorry if that was obvious to most, but I needed to clarify at least one scenario where this technique could be useful. On Sep 8, 1:23 pm, Steven Soroka <[email protected]> wrote: > I work on a team of about 5 committers Rails project in a git repo. > We often run in to issues with migrations that have run in one branch > and not another, or migrations that have run on deploy that aren't > automatically ran down when we roll back our production server to an > older version. > > I think the problem could potentially be resolved if the database > stored the code to run the down method of a migration along with the > list of migrations that have run. On rake db:migrate, if a migration > is missing, it could prompt (or accept an option) to automatically run > the down method for the missing migrations. > > I'd be happy to implement this, the only potential issue I see is the > down method in the db getting out of date with the code in the > migration file, but maybe that's not much of an issue. > > Feedback? > > Steve --~--~---------~--~----~------------~-------~--~----~ 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 [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-core?hl=en -~----------~----~----~----~------~----~------~--~---
