I was thinking the same thing. Is postgresql a database where you could put the migration in a transaction?
-prpht9 On 9 May, 10:41, dweinand <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
