Rails creating migration to add columns to table causes error when running rake db:migrate

Question

I have a model created called "users" and i created a new migration to add some columns to the users table. Now when i run rake db:migrate, I get the error below b/c it's trying to create the users table again

$ rake db:migrate
==  DeviseCreateUsers: migrating ==============================================
-- create_table(:users)
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: Table 'users' already exists: CREATE TABLE `users`.....

Why is it trying to create the table again?

Here's the command i used to create the new migration

$ rails generate migration AddDetailsToUsers home_phone:decimal cell_phone:decimal work_phone:decimal birthday:date home_address:text work_address:text position:string company:string

The new migration looks like this:

class AddDetailsToUsers < ActiveRecord::Migration
  def change
    add_column :users, :home_phone, :decimal
    add_column :users, :cell_phone, :decimal
    add_column :users, :work_phone, :decimal
    add_column :users, :birthday, :date
    add_column :users, :home_address, :text
    add_column :users, :work_address, :text
    add_column :users, :position, :string
    add_column :users, :company, :string
  end
end

EDIT

20120511224920_devise_create_users

class DeviseCreateUsers < ActiveRecord::Migration
  def change
    create_table(:users) do |t|
      ## Database authenticatable
      t.string :email,              :null => false, :default => ""
      t.string :username,           :null => false, :default => ""
      t.string :encrypted_password, :null => false, :default => ""

      ## Recoverable
      t.string   :reset_password_token
      t.datetime :reset_password_sent_at

      ## Rememberable
      t.datetime :remember_created_at

      ## Trackable
      t.integer  :sign_in_count, :default => 0
      t.datetime :current_sign_in_at
      t.datetime :last_sign_in_at
      t.string   :current_sign_in_ip
      t.string   :last_sign_in_ip

      ## Encryptable
      # t.string :password_salt

      ## Confirmable
      # t.string   :confirmation_token
      # t.datetime :confirmed_at
      # t.datetime :confirmation_sent_at
      # t.string   :unconfirmed_email # Only if using reconfirmable

      ## Lockable
      # t.integer  :failed_attempts, :default => 0 # Only if lock strategy is :failed_attempts
      # t.string   :unlock_token # Only if unlock strategy is :email or :both
      # t.datetime :locked_at

      ## Token authenticatable
      # t.string :authentication_token


      t.timestamps
    end

    add_index :users, :email,                :unique => true
    add_index :users, :reset_password_token, :unique => true
    # add_index :users, :confirmation_token,   :unique => true
    # add_index :users, :unlock_token,         :unique => true
    # add_index :users, :authentication_token, :unique => true
  end
end

20120619023856_add_name_to_users

class AddNameToUsers < ActiveRecord::Migration
  def change
    add_column :users, :first_name, :string
    add_column :users, :last_name, :string
  end
end

20121031174720_add_details_to_users.rb

class AddDetailsToUsers < ActiveRecord::Migration
  def change
    add_column :users, :home_phone, :decimal
    add_column :users, :cell_phone, :decimal
    add_column :users, :work_phone, :decimal
    add_column :users, :birthday, :date
    add_column :users, :home_address, :text
    add_column :users, :work_address, :text
    add_column :users, :position, :string
    add_column :users, :company, :string
  end
end

Answer 1

And if you need to do some dirty migrations manually:

class A < ActiveRecord::Migration
  def up
    add_column :images, :name
  end
end

A.new.migrate(:up)

Answer 2

use up and down methods. It will be useful for rollback and running specific migration file.

Please follow the syntax..

  class AddDetailsToUsers < ActiveRecord::Migration
    def self.up
      add_column :users, :home_phone, :decimal
      add_column :users, :cell_phone, :decimal
      add_column :users, :work_phone, :decimal
      add_column :users, :birthday, :date
      add_column :users, :home_address, :text
      add_column :users, :work_address, :text
      add_column :users, :position, :string
      add_column :users, :company, :string
   end

   def self.down
      remove_column :users, :home_phone
      remove_column :users, :cell_phone
      remove_column :users, :work_phone
      remove_column :users, :birthday
      remove_column :users, :home_address
      remove_column :users, :work_address
      remove_column :users, :position
      remove_column :users, :company
   end
  end


    In this case please try to migrate using version number.

Like rake db:migrate:down VERSION=version number #version number is which version you wants to migrate.

Answer 3

According to what you said you used this command to create a new migration

$ rails generate migration AddDetailsToUsers home_phone:decimal cell_phone:decimal work_phone:decimal birthday:date home_address:text work_address:text position:string company:string

Im not sure if its just a typo but it should be "AddDetailsToUser" and not "Users". Just check again and we will be able to help you. This is for devise generated model. When you mention User, in db it looks for Users.

Ruby on Rails follow linguistic convention.table_name is Plural but model_name is Singular. You have to use model_name in the command you used.

If you want to use table_name then use this

rails g migration add_details_to_users home_phone:decimal......etc

Answer 4

The error is saying that it's trying to run the original DeviseCreateUsers migration again and can't because the users table already exists.

To fix this, you can run the down migration for DeviseCreateUsers and then run migrations as normal. You can do that with:

rake db:migrate:down VERSION=20121031XXXXXXXX
rake db:migrate

Where 20121031XXXXXXXX is the date stamp of the migration name. In other words, you'll have a migration named 20120410214815_devise_create_users.rb and you copy the date stamp from the filename and paste it into the command. Here's the Rails Guide on Migrations for reference.

Edit: This is noted in the comments, but just a word of warning. Running the down migration for a table will lose any entries that table has. I assume you're running in development mode, so this shouldn't be a problem. If you're in production, you will need to take extra steps to backup the table data and reload it afterwards, otherwise you're going to have a bad day (or week maybe).

Answer 5

Check for some environmental variables that might be supplying an unexpected value for the version of your migration. I found an old question on Stack Overflow (and forgive me if it is way out of date) where db:migrate was destroying the table, instead of applying an existing new migration.

They eventually found that an environmental variable was causing db:migrate to run with a version parameter of "0" which is functionally equivalent to rake db:migrate:down

Is it possible that your situation could be caused by the version being unexpectedly changed to include or match the previous migration DeviseCreateUsers?

Answer 6

just try

in the first file

create_table(:users), :force => true do |t|

this will override any other table

Answer 7

So from what I have gathered from this:

• You already had a User model
• You have a version of this in production
• You ran a default rails generate devise:install
• You then ran rails generate devise User

I am hoping that:

• You use source control
• You check code in a lot

NOTE: If not, you are about to learn why you need to do so.

Revert your code to before you generated Devise

Hopefully, you can just create a new sandbox of a point right before generating Devise. If not, copy your project directory and do it by hand. The only other option is manually edit all the files that Devise generated.

Rerun your Devise generation

• readd gem 'devise' to your Gemfile
• rails generate devise:install
• rails generate devise MODEL

Make sure that model does not exist! If you don't you get into the problem you are currently having.

Migrate current users from one model to the other

If you can generate a script to completely move authentication information from your old user model to the new, good for you. If you are using a different hashing algorithm from Devise for your current authentication, then you are going to either invalidate all of their passwords and require your users to create a new password using a confirmation code in their email OR you could migrate users as they log in. The first method is clean, complete, and rude. The second method is ugly, incomplete, and silent. Choose your method however you like.

Edit: You could probably find a way to customize Devise to use your algorithm instead. That would probably be even better, but a little more work and fairly brittle.

Another thing is that your authentication model should not be overloaded with account data. You should have a model that only handles authentication which has_a account data model that stores whatever you might want to track about accounts.

Answer 8

Rails keeps track of the migrations in the "schema_migrations" table of your database. Unless there is an entry for "20120511224920", which is the Devise migration, it will attempt to run it again, which it appears to already exists.

You can add that manually to the table if that is the case.

Answer 9

Can you try make a fresh database and then migrate it again:

rake db:drop:all
rake db:create:all
rake db:migrate

Answer 10

I guess you ran rails generate devise user sometime which generated DeviseCreateUsers. If you have already created User model and users table, you can delete the generated migration file from db/migrate.