Thanks for your assertion. But i don't understand why database migrations can't be made atomic. for my understanding transactions in postgresql, what i'm using, are atomic.
So if migration x fails in the middle, the transaction is not commited, and so no change would be made by the rails migration in db. i don't think that are steps that can't be undone. at least with postgresql. don't know much about mysql or other databases. so what are non-transactionable statements? do you have an example for me? if i only have one migration running after my deploy, i think running deploy_with_migrations should do the job. cause if this migration fails, for my understanding, nothing is changed in the db, and the app isn't updated. if you have more than one migration, and the last migration fails, it's possible that you have the database in a not determinable state for the application. but the state of my db itself is always determinable. On 9 Mai, 11:02, Andrew Vit <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
