> Doesn't this same problem exist always - whether you are going down or > up, or store your migrations in files or the database? Some would > consider it an antipattern to put any models or app classes in your > migrations.
Some would be wrong if they considered that an anti pattern ;). The vast bulk of migrations in my projects are model-dependent for things like cleaning up a data problem in production, initialising counter fields based on non-sql-calculatable fields (e.g. API calls) If you store the migrations in your version control system you can recover the state of the migrations at any point in time. For a particularly tricky down migration you can always step back revisiion by revision. The database would have no such history and could never provide the same level of fidelity or reliability that your SCM can. > I'm still not clear on the original poster's root problem and > solution, but I don't think the possibility of outdated non-schema > migration code is a good reason to reject the idea. The specific case mentioned was rolling back when the checkout is at an older version and doesn't have the down migration. The solution there is to rollback from the original revision. If there's another case I'd be happy to re-evaluate but the power of migrations is in their simplicity they're not some darcs-ish patch algebra for DDL, they're little scripts that you run in order in which you can do whatever you want. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
