Forum: Ruby on Rails Are migrations executed within a transaction?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
41165a7e7126d616a0ae0762e00718e2?d=identicon&s=25 BigSmoke (Guest)
on 2006-01-06 22:49
(Received via mailing list)
Hi all,

Can I safely assume that each migration is excuted within a
transaction, so that's it's safe to have migrations executing failing
statements?

Thanks,

  - Rowan
5b9fe87ec1faa67a4599782930f45ec9?d=identicon&s=25 Sam Stephenson (Guest)
on 2006-01-07 00:43
(Received via mailing list)
Hi,

On 1/6/06, BigSmoke <bigsmoke@gmail.com> wrote:
> Can I safely assume that each migration is excuted within a
> transaction, so that's it's safe to have migrations executing failing
> statements?

Migrations aren't run inside a transaction because they can't be.
None of the databases supported by Rails are able to perform DDL
operations (CREATE TABLE, ALTER TABLE, etc.) inside a transaction
(some raise errors, the others silently fail).

Always run your migrations on test data first!

--
sam
41165a7e7126d616a0ae0762e00718e2?d=identicon&s=25 BigSmoke (Guest)
on 2006-01-07 02:25
(Received via mailing list)
On 1/7/06, Sam Stephenson <sstephenson@gmail.com> wrote:
> (some raise errors, the others silently fail).
I always had the impression that this did work in my Postgres
installation. Perhaps this could be because I created the schema's in
the same transaction as in which I created the tables, views and
functions?

> Always run your migrations on test data first!

No worries! I was going to do that anyway :-) It can't be pointed out
often enough, though. I just thought it would be an easy way to undo
incomplete migrations in case of errors. Luckily, now that I'll use
migrations to load the initial (schema) data, reloading all my schemas
if something goes wrong will be less of a pain. AR makes life a whole
lot easier again :-)

  - Rowan
0091f92762685860109bbcb02edfdf27?d=identicon&s=25 Alain Ravet (Guest)
on 2006-01-07 11:14
(Received via mailing list)
Sam Stephenson wrote:
    > Migrations aren't run inside a transaction because they can't be.
    > None of the databases supported by Rails are able to perform DDL
    > operations (CREATE TABLE, ALTER TABLE, etc.) inside a transaction


Additionally, migration can do more than DDL, even non-DB related
operations (like generating a scaffold, executing plain ruby code,..).
So, the DB part of the migration can work fine, while the rest failed.
rolling back in that case can be tricky. My workaround is to write many
smaller migrations, instead of a big one.

Alain
8a00145d61d84b58c4688cdc50bac48f?d=identicon&s=25 Wiebe Cazemier (halfgaar)
on 2006-01-11 17:41
Sam Stephenson wrote:
> Migrations aren't run inside a transaction because they can't be.
> None of the databases supported by Rails are able to perform DDL
> operations (CREATE TABLE, ALTER TABLE, etc.) inside a transaction
> (some raise errors, the others silently fail).

I just ran a test on my postgres DB:

sicirec_dev=# select * from investment_forms;
 id | name_id
----+---------
  1 |      34
  2 |      35
(2 rows)

sicirec_dev=# BEGIN;
BEGIN
sicirec_dev=# alter table investment_forms add column foobar INTEGER;
ALTER TABLE
sicirec_dev=# select * from investment_forms;
 id | name_id | foobar
----+---------+--------
  1 |      34 |
  2 |      35 |
(2 rows)

sicirec_dev=# ROLLBACK;
ROLLBACK
sicirec_dev=# select * from investment_forms;
 id | name_id
----+---------
  1 |      34
  2 |      35
(2 rows)

So, it does seem to work. Am I being too simple with my alter table
perhaps?
This topic is locked and can not be replied to.