Rails: I update migration file then run db:migrate, but my schema isn't updating

Question

I'm trying to add an extra field to one of my tables.

I've added the field in the migration file (under db\migrate), then ran 'rake db:migrate' which ran without troubles. My text editor even told me my schema.db file has been updated and needs to refresh.

The schema file does not contain my new field and any attempts to reference the field from my views fail miserably.

How do I do this? It is possible to update a table with an extra field via rails without having to totally drop and recreate the database again?

score 44 · Accepted Answer · edited Dec 23 '13 at 15:47

44

http://guides.rubyonrails.org/migrations.html#changing-existing-migrations

Occasionally you will make a mistake when writing a migration. If you have already run the migration then you cannot just edit the migration and run the migration again: Rails thinks it has already run the migration and so will do nothing when you run rake db:migrate. You must rollback the migration (for example with rake db:rollback), edit your migration and then run rake db:migrate to run the corrected version.

edited Dec 23 '13 at 15:47

random-forest-cat

33,652
11
120
99

answered May 26 '12 at 16:22

utapyngo

6,946
3
44
65

This was a convenient solution for me since my DB changes weren't being used by others yet. But I think for many others, creating a new migration would be safer than rolling back your migration which undoes the modifications that the migration made to your schema. But I'm new to Rails, so perhaps someone with more experience can explain when to use which option? – Dennis Jan 22 '14 at 15:50
4

If you have already released (or commited, it depends on the workflow) the existing migration, you should create a new migration rather than editing the existing one. From the other hand, if you have applied a newly created migration and understood that you have missed something right after that, you should rollback and edit the migration to avoid the mess with too many useless migrations. – utapyngo Jan 23 '14 at 08:14

score 7 · Answer 2 · answered Sep 13 '09 at 03:28

You should always create a new migration file when adding/changing something in the database. This is the purpose of migrations. A migration file should have the ability to make the new change and undo the change. This way if something goes wrong or you changed your mind you can easily roll back to a previous migration.

The following link's sections labeled 'Anatomy of a Migration' and 'Writing a Migration' might be of help to you.

http://guides.rubyonrails.org/migrations.html

Even when it sounds so good, I've NEVER done a rollback. But it's true, that's what's supposed to be good about migrations... — Luis Ortega Araneda, Jul 21 '15 at 19:46

score 6 · Answer 3 · edited May 23 '17 at 12:17

I did the same thing, I wanted to change a field name and instead of this:

class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.string :commenter
      t.text :body

      # this line adds an integer column called `article_id`.
      t.references :article, index: true

      t.timestamps
    end
  end
end

I changed

  t.text :body

to

t.text :comment_body

I tried doing rake

db:migrate

nothing happened as in it went to the command prompt again without any output..., i looked at stack overflow and this guided me to do rake

db:migrate:redo

with out put

== 20141129044056 CreateComments: reverting ===================================
-- drop_table(:comments)
   -> 0.0000s
== 20141129044056 CreateComments: reverted (0.0886s) ==========================

== 20141129044056 CreateComments: migrating ===================================
-- create_table(:comments)
   -> 0.0040s
== 20141129044056 CreateComments: migrated (0.0040s) ==========================

and then I loaded my page/controller with commenter_body instead of body and it loaded perfectly.

I think this is also a solution to the same. I dont know if there is any issue in the underneath workings in the model/DB( i am still very new to RoR,my third day actually...)

This is a really nice solution for doing a rollback and then migrating back up again in one swift move. http://edgeguides.rubyonrails.org/active_record_migrations.html#rolling-back — atw, Jan 13 '15 at 10:40

score 4 · Answer 4 · edited Jan 13 '15 at 11:25

4

Solved my own Question..

Basically rather than edit the original migration files generated when you run scaffolding you create a new migration file just for what you want to acheive:

http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration

edited Jan 13 '15 at 11:25

atw

5,428
10
39
63

answered Sep 13 '09 at 01:57

Evolve

8,939
12
51
63

score 2 · Answer 5 · answered Mar 19 '14 at 19:43

2

I was able to regenerate my schema with latter migrations by running rake db:schema:dump

answered Mar 19 '14 at 19:43

random-forest-cat

33,652
11
120
99

score 0 · Answer 6 · answered Jul 24 '11 at 11:57

0

Once u do rake db:migrate then again u cannot add column to that file.You have to generate a new migration file by using rails g migration add_columnname_to_tablename for adding that particular column and do rake db:migrate.That's it !!!

answered Jul 24 '11 at 11:57

Kranthi

1,377
1
17
34

score -1 · Answer 7 · answered Sep 13 '09 at 01:33

Don't know if this applies, but it's worth a shot. Straight from "Agile Development with Rails, 3rd edition":

Sometimes this schema_migrations table can cause you problems. For example, if you create the migration source file and run db:migrate before you add any schema-defining statements to the file, the database will think it has been updated, and the schema info table will contain the new version number.
If you then edit that existing migration file and run db:migrate again, Rails won’t know to apply your new changes. In these circumstances, it’s often easiest to drop the database, re-create it, and rerun your migration(s).

Rails: I update migration file then run db:migrate, but my schema isn't updating

7 Answers7

Linked