# Migration commits when run by itself (db:migrate:up), but not with other migrations (db:migrate)

**URL:** <https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327>\
**Category:** Rails\
**Created:** [February 11, 2010, 8:24pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327 "2010-02-11T20:24:41Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 8:24pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/1 "2010-02-11T20:24:41Z")

</div>

I have a migration that saves correctly to the database when it’s run  
by itself through db:migrate:up, but not when it’s run with other  
migrations through db:migrate.

class SetActiveOnExistingItems \< ActiveRecord::Migration  
def self.up  
Item.all.each do |item|  
if item.item\_status == Item::STATUS\_REVIEW  
item.active = false  
elsif item.item\_status == Item::STATUS\_IN\_PROGRESS  
item.active = false  
else  
item.active = true  
end  
puts “setting item\_id = #{item.id} to active = #{item.active}”  
item.save!  
puts “setting item\_id = #{item.id} to active = #{item.active}”  
item = Item.find(item.id)  
puts “setting item\_id = #{item.id} to active = #{item.active}”  
end  
end

def self.down  
Item.all.each {|item| item.active = nil; item.save(false)}  
end  
end

The output during db:migrate is:  
setting item\_id = 1 to active = true # (this one is before the save)  
setting item\_id = 1 to active = true # (this one is after the save)  
setting item\_id = 1 to active = # (this one is after the lookup)  
…

During db:migrate:up, it works as expected:  
setting item\_id = 1 to active = true  
setting item\_id = 1 to active = true  
setting item\_id = 1 to active = true  
…

For some reason, the data appears to not be actually committed to the  
database during db:migrate, while it is during db:migrate:up. There’s  
no exception thrown by save!, no indicator that I can see that the  
save is unsuccessful. Even if it was, why would it only be  
unsuccessful during a regular migration run, and not during  
db:migrate:up?

Has anyone seen this before? Do you have any idea what could cause  
this?

Thanks.

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 8:37pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/2 "2010-02-11T20:37:00Z")

</div>

Sorry, I should have mentioned - the migration before it is one where  
that active column is added. The migration after alters a column in a  
different table. The column is definitely added before this migration  
runs.

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 10:00pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/3 "2010-02-11T22:00:07Z")

</div>

I tried doing the whole thing in one migration - adding the column and  
setting the value, and I got the exact same behavior with this  
migration:

class AddActiveToItems \< ActiveRecord::Migration  
def self.up  
add\_column :items, :active, :boolean  
Item.all.each do |item|  
if item.item\_status == Item::STATUS\_REVIEW or item.item\_status  
== Item::STATUS\_IN\_PROGRESS  
item.active = false  
else  
item.active = true  
end  
item.save!  
puts “id: #{item.id}, active: #{item.active}”  
puts “id: #{item.id}, active: #{Item.find(item.id).active}”  
end  
end

def self.down  
remove\_column :items, :active  
end  
end

for db:migrate:  
id: 1, active: true  
id: 1, active:

for db:migrate:up:  
id: 1, active: true  
id: 1, active: true

There must be something weird about this data manipulation.

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 10:35pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/4 "2010-02-11T22:35:15Z")

</div>

Oh also “Item.reset\_column\_information” needs to be after the  
add\_column and before the Item.all.each if you are adding the column  
and manipulating the data in the same migration. If it is 2 separate  
migrations, just put it at the top of the 2nd one.

Jarin U.  
Robot Mode LLC  
[http://robotmo.de](http://robotmo.de)

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 10:44pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/5 "2010-02-11T22:44:02Z")

</div>

Sure enough, I see that exact information in the Migration  
documentation.

> **[ActiveRecord::Migration](https://api.rubyonrails.org/classes/ActiveRecord/Migration.html)**
>
> Active Record Migrations Migrations can manage the evolution of a schema used by several physical databases.

It works great now. Thank you.

Adam

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 10:32pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/6 "2010-02-11T22:32:19Z")

</div>

You need to put “Item.reset\_column\_information” at the top of the  
migration so Rails reloads the altered table.

Jarin U.  
Robot Mode LLC  
[http://robotmo.de](http://robotmo.de)

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 11, 2010, 11:54pm UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/7 "2010-02-11T23:54:52Z")

</div>

On Feb 11, 9:42 pm, Adam [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Sure enough, I see that exact information in the Migration documentation.[ActiveRecord::Migration](http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)  
> It works great now. Thank you.

You should also be careful about using model classes in migrations -  
because your source is updated in one go but migrations run one by one  
it’s easy enough to run into trouble. For example if your model has a  
validation on a column that is added by migration two and migration  
one tries to create some objects of that class then it will fail  
because of the validation on the not yet existent column

Fred

---

<div class="post-metadata">

**Author:** ![asetzler](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ac91a4/32.png) [@asetzler](https://www.ruby-forum.com/u/asetzler)\
**Post date:** [February 12, 2010, 12:57am UTC](https://www.ruby-forum.com/t/migration-commits-when-run-by-itself-dbup-but-not-with-other-migrations-db-migrate/183327/8 "2010-02-12T00:57:58Z")

</div>

Frederick C. wrote:

> On Feb 11, 9:42�pm, Adam [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > Sure enough, I see that exact information in the Migration documentation.[ActiveRecord::Migration](http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)  
> > It works great now. Thank you.
> 
> You should also be careful about using model classes in migrations -  
> because your source is updated in one go but migrations run one by one  
> it’s easy enough to run into trouble. For example if your model has a  
> validation on a column that is added by migration two and migration  
> one tries to create some objects of that class then it will fail  
> because of the validation on the not yet existent column

And this is why it’s now considered preferable to use rake  
db:schema:load when setting up a server from scratch. Migrations are  
primarily for migration

> Fred

Best,  
–Â  
Marnen Laibow-Koser  
[http://www.marnen.org](http://www.marnen.org)  
removed\_email\_address@domain.invalid