Rake just one migration

Question

I'm trying to run just one migration out of a whole bunch in my rails app. How can I do this? I don't want to run any of the migrations before or after it. Thanks.

This would be a convenient rails feature: add a `STEP=n` argument to `db:migrate` (where `n` is the number of migrations to run, just like there is for `db:rollback`) - then you could do `rake db:migrate STEP=1` or `rake db:migrate STEP=2`, etc. — user664833, Mar 26 '17 at 22:46

score 173 · Accepted Answer · answered Aug 26 '09 at 03:04

173

rake db:migrate:redo VERSION=xxxxxxx, but that will run the down and then the up step. You could do this in conjunction with commenting out the down step temporarily.

answered Aug 26 '09 at 03:04

Ryan Bigg

106,965
23
235
261

Hmm, http://blog.stonean.com/2007/12/18/rake-dbmigrateredo/, ::redo doesn't seem to take a VERSION argument. – Terry G Lorber Aug 26 '09 at 03:07
It works, I tested it. Note that the article is from TWO THOUSAND AND SEVEN. Rails changes a lot during that time. – Ryan Bigg Aug 27 '09 at 03:00
Then why should Stackoverflow display outdated info? If you now run `rake -T` there's no task called `db:migrate:redo` – Pedro Rolo Oct 12 '11 at 15:34
3

@pedrorolo: This is not outdated. This task has no description and so it will not show up in `rake -T`. – Ryan Bigg Oct 12 '11 at 19:56
1

@pedrorolo: `db:test:prepare` also doesn't show up on that list. God I'm late to the party. – mraaroncruz Dec 28 '11 at 20:14
The undescribed tasks don't display on that list. That's a "feature" of Rake. – Ryan Bigg Dec 30 '11 at 00:40
use rake -P to list all tasks along with their dependencies, even the ones without descriptions – Patrick Glandien Jul 04 '12 at 10:56
9

To expand on what Ryan says, if the table has been dropped from the database outside of Rails, `rake db:migrate:up VERSION=my_version` may do _nothing_, because the schema_migrations table still says it is has been run. In the same situation `rake db:migrate:redo VERSION=my_version` may _fail_ because it cannot drop the table. In this case, comment out the `down` method in the migration temporarily and re-run `rake db:migrate:redo...` – Leo Sep 08 '12 at 11:56
3

And to expand what @Leo says, if the migration is defined with def change, then change it to def self.up in addition to the above. – valk Mar 09 '14 at 23:04
Noteworthy, `VERSION` is just an environment variable so it can come first in the command or even set previous to the command: `VERSION=xxxxxxx rake db:migrate:redo` – Joshua Pinter Nov 18 '18 at 19:35

score 76 · Answer 2 · answered Aug 26 '09 at 09:03

76

rake db:migrate:up VERSION=1234567890

similarly rake db:migrate:down to take a specific migration down. You can get a list of available rake tasks with rake -T.

answered Aug 26 '09 at 09:03

Shadwell

34,314
14
94
99

6

The `VERSION` mentioned here is the integer value at the beginning of each of your migration files (which is just the timestamp of when it was created). For example, `VERSION=20150720023630`. – aaron-coding Jul 20 '15 at 21:36
3

The versions are displayed nicely with rake db:migrate:status – jpgeek Jul 10 '17 at 06:19
Noteworthy, `VERSION` is just an environment variable so it can come first in the command or even set previous to the command: `VERSION=1234567890 rake db:migrate:up` – Joshua Pinter Nov 18 '18 at 19:35

score 25 · Answer 3 · answered Sep 13 '09 at 08:37

25

I've had to run a single migration that changed and needed to be re-run independently of all other migrations. Fire up the console and do this:

>> require 'db/migrate/your_migrations.rb'
=> ["YourMigrations"]
>> YourMigrations.up
=> etc... as the migration runs
>> YourMigration.down

More usefully this could be put into a rake task etc.

answered Sep 13 '09 at 08:37

6

This worked awesomely. You can also just copy-paste the code from the migration into the console to define the class (and this allows for manual manipulation if needed, if you just made a mistake on Dev, for example). If you defined a reversible migration with `change`, run `YourMigrations.migrate(:up)` instead (or `:down` too!) – trisweb Mar 12 '13 at 16:57
1

you might have to `require "#{Rails.root}/db/migrate/your_migrations.rb"` – s2t2 Jun 11 '15 at 19:03

score 19 · Answer 4 · edited May 11 '17 at 00:27

19

rake db:migrate:up VERSION=version_no

Will migrate( add) specific migration script

rake db:migrate:down VERSION=version_no

Will delete specific migration script

edited May 11 '17 at 00:27

JP.

257
1
3
8

answered Jun 02 '13 at 10:34

reshma

641
1
11
18

score 14 · Answer 5 · answered Aug 25 '09 at 22:30

14

rake db:migrate VERSION=20098252345

give that a try.

answered Aug 25 '09 at 22:30

JP Silvashy

46,977
48
149
227

8

I think this will run any migrations up to the one you specified. – Ken Liu Aug 25 '09 at 22:33
1

close, but that also runs any migrations before the specific migration. – Anon Aug 25 '09 at 22:35
6

I don't think you should/want to run only one migration without considering the ones before it. A migration is a representation of the databases structure as it relates to the code at a given point in time , and thus the migrations before it are necessary. If you only want to run _one_ migration it's likely you didn't write the proper up/down operations to keep the migrations functional... it's a bad habit to only write your up migrations. – JP Silvashy Aug 25 '09 at 23:25
1

Noteworthy: `VERSION` is just an environment variable so it can come first in the command or even set previous to the command: `VERSION=20098252345 rake db:migrate` – Joshua Pinter Nov 18 '18 at 19:35

score 5 · Answer 6 · answered Nov 24 '14 at 03:08

rake db:migrate:redo version='xxxx'

Remember to put the quotation mark around xxxx, xxxx is the timestamp (or Migration ID) for your migration.

You may check the timestamps (Migration ID) for the previous migrations you've done by using

rake db:migrate:status

score 3 · Answer 7 · answered May 20 '14 at 13:31

Expanding on the answer by korch above, require did not work for me, but load did. To be concrete, for the migration file:

    class ChangeMinQuantityToRaces < ActiveRecord::Migration
      def change
        change_column :races, :min_quantity, :integer, :default => 0
      end
    end

in the console typing

    > load 'db/migrate/30130925110821_change_min_quantity_to_races.rb'
    > ChangeMinQuantityToRaces.new.change

worked for me.

    > Race.new.min_quantity # => 0

This was for ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux] and Rails 3.2.13.

score 3 · Answer 8 · answered Jan 08 '15 at 18:30

Adding my 2¢ to this because I ran into this same issue:

If you absolutely want to run a migration over again without creating a new one, you can do the following:

rails dbconsole -p devdb=# delete from public.schema_migrations where version = '20150105181157';

And rails will "forget" that it ran the migration for 20150105181157. Now when you run db:migrate it will run it again.

This is almost always a bad idea though. The one instance where it could make sense is if you have a development branch and you haven't fleshed out your migration yet and want to add some things to it in development. But even then it's better to make your migration 2-way so you can properly rollback and retry repeatedly.

score 1 · Answer 9 · answered Aug 26 '09 at 02:54

There's got to be a way to run the migration class via the console. I can't seem to get the migrations code to be recognizable.

However, as the comments indicate, it's preferred to run the migrations in order. Use:

rake db:migrate VERSION=##########

Copy and paste your code in the migration to script/console?

score 1 · Answer 10 · answered Jun 15 '11 at 03:52

I have a utility method that makes this very easy in development. I find that it helps me avoid creating too many migrations--normally I modify migrations until they have been deployed.

http://fullware.net/index.php/2011/05/26/easily-load-rails-migrations-for-console-execution/

Greg Blass · Answer 11 · 2016-10-06T20:39:55.760

I use this technique in development when I change a migration a significant amount, and I don't want to migrate down a ton and lose any data in those along the way (especially when I'm importing legacy data that takes a long time that I don't want to have to re-import again).

This is 100% hackish and I would definitely not recommend doing this in production, but it will do the trick:

Move migration that you want to re-run out of its directory to a temporary place
Generate another migration with the same name
Copy/paste the original migration code into the newly generated migration file
Run the new migration
Delete the newly generated migration file
Edit your schema migrations to remove the most recent value
Restore the old migration file

Rake just one migration

11 Answers11

Linked