>From the PostgreSQL Documentation: A transaction is said to be atomic: from the point of view of other transactions, it either happens completely or not at all. http://www.postgresql.org/docs/8.2/interactive/tutorial-transactions.html
so if you put you migration into a transaction and it fails in the middle, everything done so far will be reverted. a migration is never be half-done. whats about mysql and the others? are there no transactions available in the database? does a mysql database really stay in the state where the migrations fails? not for real? On 10 Mai, 14:39, prpht9 <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---