Run a single migration file

Question

Is there an easy way to run a single migration? I don't want to migrate to a certain version I just want to run a specific one.

Is this something that you ran once as a migration because it happened to be needed, then turns out to be a useful query that might need to get run a number of times? perhaps you should refactor the contents of the migration into a model or other object, then have the migration reference that new location. Then you can simply execute the new object at your lesure by invoking ruby on the command line. — Nathan Feger, Apr 15 '09 at 22:09

score 504 · Answer 1 · edited Jun 30 '18 at 15:23

504

Assuming fairly recent version of Rails you can always run:

rake db:migrate:up VERSION=20090408054532

Where version is the timestamp in the filename of the migration.

Edit: At some point over the last 8 years (I'm not sure what version) Rails added checks that prevent this from running if it has already been run. This is indicated by an entry in the schema_migrations table. To re-run it, simply execute rake db:migrate:redo VERSION=20090408054532 instead.

edited Jun 30 '18 at 15:23

grepsedawk

3,324
2
26
49

answered Apr 15 '09 at 22:30

gtd

16,956
6
49
65

This will run migrations up to that version. I was looking for a way to run just a specific migration. – nan Apr 17 '09 at 20:47
129

Actually the command is rake db:migrate:redo VERSION=my_version – Chirag Patel Sep 14 '10 at 01:04
25

redo runs the down-method of the given migration and the up method after that. up runs only the up-method, and I think that is exactly what the asking person wants. – Sven Koschnicke Nov 09 '11 at 07:58
In rails 3.1.3, redo struggles sometimes with older migrations. require + #up works great. – Matt Sanders Feb 09 '12 at 18:45
7

'up' appears to not run if the database schema version is later than the migration in question, which can happen when merging another person's changes, for example. – Matt Connolly Mar 28 '12 at 02:12
3

Thanks, I used this for down with `rake db:migrate:down VERSION=XXX` – Nitrodist Oct 30 '12 at 13:57
1

for any noobs like me wondering: rake db:migrate:status to get the timestamp. (someone pls correct me if i'm wrong.) – BenKoshy Aug 31 '15 at 00:12

score 278 · Accepted Answer · edited Mar 06 '23 at 18:02

278

You can just run the code directly out of the ruby file:

rails console
>> require "db/migrate/20090408054532_add_foos.rb"
>> AddFoos.new.up

Note: Very old versions of rails may require AddFoos.up rather than AddFoos.new.up. If your migration has a "change" method, you need to run AddFoos.new.change.

An alternative way (without IRB) which relies on the fact that require returns an array of class names:

script/runner 'require("db/migrate/20090408054532_add_foos.rb").first.constantize.up'

Note that if you do this, it won't update the schema_migrations table, but it seems like that's what you want anyway.

Additionally, if it can't find the file you may need to use require("./db/..." or try require_relative depending on your working directory

edited Mar 06 '23 at 18:02

Rob

4,404
2
32
33

answered Apr 16 '09 at 00:25

Orion Edwards

121,657
64
239
328

73

Sometimes you need a './' in front of the require path, and it definitely doesn't update the schema_migrations. – Beardo Aug 26 '11 at 15:26
1

`script/runner 'require("db/migrate/20090408054532_add_foos.rb").first.constantize.up'` This seems like a cool trick. But `require` now returns either true or false. Is there a workaround? – Siddhant Aug 30 '12 at 15:43
14

I had to create an instance of the migration object before I could call up. e.g. `AddFoos.new.up` – Bentleyo Oct 30 '12 at 05:43
17

So, to sum up for Rails 3.2: `require "./db/migrate/db/migrate/20090408054532_add_foos.rb"` then `AddFoos.new.up` – trisweb Jan 11 '13 at 21:39
62

If your migration uses `change` instead of `up` and `down`, you'll need to run `AddFoos.new.migrate(:up)` – Don Werve Jan 21 '13 at 12:41
@DonWerve thank you for this comment! I was following the root answer and getting nothing, your comment got me what I needed. – asfallows Jun 07 '13 at 12:49
6

In rails 4, you can call `AddFoos.new.change` – random-forest-cat Dec 23 '13 at 16:02
Use ```require "#{Rails.root}/db/migrate/20090408054532_add_foos.rb"``` – Luan D Oct 27 '15 at 08:29
just change `require` to `require_relative` in newer versions of Ruby 2. I don't see any other answers recommending that. You don't have to change the relative path string at all - hence - require_relative :) – danielricecodes Jul 27 '18 at 22:14
perfect solution !! – Sukhbir Aug 04 '18 at 10:11
The answer should be updated with comment made by @Beardo. – opensource-developer Nov 06 '20 at 10:29

Benjamin Crouzier · Answer 3 · 2015-11-02T10:07:32.077

If you want to run a specific migration, do

$ rake db:migrate:up VERSION=20080906120000

If you want to run migrations multiple times, do

# use the STEP parameter if you need to go more than one version back
$ rake db:migrate:redo STEP=3

If you want to run a single migration multiple times, do

# this is super useful
$ rake db:migrate:redo VERSION=20080906120000

(you can find the version number in the filename of your migration)

Edit: You can also simply rename your migration file, Eg:

20151013131830_my_migration.rb -> 20151013131831_my_migration.rb

Then migrate normally, this will treat the migration as a new one (usefull if you want to migrate on a remote environment (such as staging) on which you have less control.

Edit 2: You can also just nuke the migration entry in the database. Eg:

rails_c> q = "delete from schema_migrations where version = '20151013131830'"
rails_c> ActiveRecord::Base.connection.execute(q)

rake db:migrate will then rerun the up method of the nuked migrations.

Both "up" and "redo" didn't work for me, but deleting the row in schema_migrations was perfect. — cesoid, Jul 26 '16 at 19:36

score 31 · Answer 4 · answered Jul 24 '13 at 21:20

31

If you've implemented a change method like this:

class AddPartNumberToProducts < ActiveRecord::Migration
  def change
    add_column :products, :part_number, :string
  end
end

You can create an instance of the migration and run migrate(:up) or migrate(:down) on an instance, like this:

$ rails console
>> require "db/migrate/20090408054532_add_part_number_to_products.rb"
>> AddPartNumberToProducts.new.migrate(:down)

answered Jul 24 '13 at 21:20

chibicode

3,769
5
25
27

1

This also applies even if you're using `up` and `down`. – gak Aug 22 '13 at 06:25
worked for me to run the migration AddPartNumberToProducts.new.migrate(:up) but strange thing is that this AddPartNumberToProducts.up does not worked – Taimoor Changaiz Oct 09 '20 at 11:36

score 19 · Answer 5 · edited Sep 28 '15 at 02:55

19

This are the steps to run again this migration file "20150927161307_create_users.rb"

Run the console mode. (rails c)

Copy and past the class which is in that file to the console.

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :name
      t.string :email
      t.timestamps null: false   end
    end
  end
end

Create an instance of the class CreateUsers: c1 = CreateUsers.new
Execute the method change of that instance: c1.change

edited Sep 28 '15 at 02:55

mbinette

5,094
3
24
32

answered Sep 28 '15 at 02:47

rolph dzounga

199
1
3

just require the file with the class, e.g. in the console: `require "./db/migrate/20150927161307_create_users.rb"` instead of copy & pasting. You can then run the class the same way by instantiating and calling the method defined in the class `CreateUsers.new.change`. – VinnyQ77 Feb 15 '20 at 00:06
perfect! Thank you – Nezir Oct 26 '20 at 18:17

score 17 · Answer 6 · edited Sep 23 '17 at 17:33

17

As of rails 5 you can also use rails instead of rake

Rails 3 - 4

# < rails-5.0
rake db:migrate:up VERSION=20160920130051

Rails 5

# >= rails-5.0
rake db:migrate:up VERSION=20160920130051

# or

rails db:migrate:up VERSION=20160920130051

edited Sep 23 '17 at 17:33

Graham

7,431
18
59
84

answered Sep 20 '16 at 13:05

Deepak Mahakale

22,834
10
68
88

1

it also guess what you need with `rails db:migrate VERSION=20160920130051` – frenesim Nov 03 '16 at 18:41

Tasos Anesiadis · Answer 7 · 2019-09-19T06:03:26.253

If you want to run it from console, this is what you are looking for:

$ rails console
irb(main)> require "#{Rails.root.to_s}/db/migrate/XXXXX_my_migration.rb"
irb(main)> AddFoo.migrate(:up)

I tried the other answers, but requiring without Rails.root didnt work for me.

Also, .migrate(:up) part forces the migration to rerun regardless if it has already run or not. This is useful for when you already ran a migration, have kinda undone it by messing around with the db and want a quick solution to have it up again.

score 14 · Answer 8 · answered Oct 23 '14 at 10:18

14

If you're having trouble with paths you can use

require Rails.root + 'db/migrate/20090408054532_add_foos.rb'

answered Oct 23 '14 at 10:18

Dejan Cancarevic

187
1
7

score 5 · Answer 9 · answered May 26 '15 at 08:41

Method 1 :

rake db:migrate:up VERSION=20080906120000

Method 2:

In Rails Console 1. Copy paste the migration class in console (say add_name_to_user.rb) 2. Then in console, type the following

Sharding.run_on_all_shards{AddNameToUser.up}

It is done!!

score 5 · Answer 10 · answered Feb 26 '12 at 02:27

5

Please notice that instead of script/runner, you may have to use rails runner on new rails environments.

answered Feb 26 '12 at 02:27

viniciusnz

107
1
6

score 1 · Answer 11 · answered Apr 10 '18 at 07:57

Looks like at least in the latest Rails release (5.2 at the time of writing) there is one more way of filtering the migrations being ran. One can pass a filter in a SCOPE environment variable which would be then used to select migration files.

Assuming you have two migration files 1_add_foos.rb and 2_add_foos.run_this_one.rb running

SCOPE=run_this_one rails db:migrate:up

will select and run only 2_add_foos.run_this_one.rb. Keep in mind that all migration files matching the scope will be ran.

Run a single migration file

11 Answers11

Linked

Related