>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
-~----------~----~----~----~------~----~------~--~---

Reply via email to