Yes, I think you're misunderstanding a few things about transactions, migrations, and how they correspond to code releases: in fact, they don't really correspond. They're independent things.
Unfortunately, database migrations can't be made atomic. Even in a transaction, there are things that can't be performed transactionally such as altering tables. It's not really a rails/migration limitation, it has to do with the way databases work. Some steps simply can't be undone. A migration with fully transactionable statements will either succeed, or fail cleanly with a transaction rollback. But if you have any non- transactionable statement and it fails, you'll be left in the middle of a migration and just rolling back your application code at that point won't necessarily help anything. You'll have to intervene to get the database back to a consistent state. If you have a migration that you don't feel 100% confident about running cleanly, which performs non-transactionable, non-undoable statements, you should at least run the task disable_web to take the site offline while you apply it and check that it completes. Another thing I do is take a backup of the live database and load it into my development or staging database and test the questionable migration there before applying it live. That said, the task deploy_with_migrations will do exactly what you're asking for within the limits I described. It will run update_code and migrate in one step, but linking to the new release only happens after the database is migrated, so if it fails you'll still be linked to the original release. --Andrew Vit On 8 May, 05:41, dweinand <[EMAIL PROTECTED]> wrote: > Hello, > i'm just looking for a solution to rollback my app after a migration > failed. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
