28
votes

I have a rails migration that is not being applied to my schema.rb. The migration should create a table:

class CreateUserGraphs < ActiveRecord::Migration
  def change
    create_table :user_graphs do |t|
      t.string :name
      t.string :content
      t.integer :user_id
      t.string :type_id
      t.integer :upload_id

      t.timestamps
    end

    add_index :user_graphs, [:user_id, :created_at]
  end
end

I did db:reset. Then I tried rake db:migrate:up VERSION=123123123(this is the migration #). I am in my "dev" environment.

Why is the migration not affecting schema.rb?

6
Did you try to drop the database first? rake db:drop db:create db:migrateVucko
Interesting that worked. How does rake db:drop db:create differ from rake db:reset?Don P
rake db:reset runs db:create db:schema:load db:seed without the migrations. I think that db:migrate:reset will suit your needs.Vucko
@Vucko, please add this suggestion as a valid answer to the question ;)marzapower

6 Answers

55
votes

From the documentation:

The rake db:reset task will drop the database, recreate it and load the current schema into it.

This is not the same as running all the migrations. It will only use the contents of the current schema.rb file. If a migration can't be rolled back, 'rake db:reset' may not help you. To find out more about dumping the schema see 'schema dumping and you.'

So rake db:reset => db:drop db:create db:schema:load db:seed

To run all the migrations, use : rake db:drop db:create db:migrate

Or db:migrate:reset=> rake db:drop db:create db:migrate

Reference

3
votes

I had the same issue. I am working in development environment (with Passenger and Apache). Production and development environments use the same database.

When I run rake db:migrate, the db was changed, but the schema was not updated. Then I run rake db:migrate RAILS_ENV=development, and now the schema was updated.

Seems that rails/rake are confused about my environment. Passenger sets a development environment for this site, but rake aboutsays "Environment production".

1
votes

'Versions' of migrations are done via timestamps. Rails checks which migrations it needs to run by comparing the timestamp of the last run migration and seeing if there are any newer.

If the version of your new migration is 123123123, it will not be run as that number is not greater than the current timestamp (eg. 20131209170300).

1
votes

I had the same issue... it turns out it was because I edited the name of my migration file to look neater. Make sure you don't delete the time stamp in the migration file title like I did.

I deleted the migration file, the model, the controller, and associated tests and re-generated the controller and model which fixed the problem.

1
votes

First you try to down you migration

rake db:migrate:down VERSION=20180605141404 # "VERSION=20180605141404 your migration version"

And again up your migration

rake db:migrate:up VERSION=20180605141404 #"VERSION=20180605141404 your migration version"

0
votes

Found a way to obtain an error description. ran rake db:migrate:reset and received

`SQLite3::SQLException: Cannot add a NOT NULL column with default value NULL: ALTER TABLE "rooms" ADD "priority" integer NOT NULL/usr/local/rvm/gems/ruby-2.2.1/gems/sqlite3-1.3.9/lib/sqlite3/database.rb:91:in `initialize`'