为什么在向表中添加新列时不再能耙db：migrate了？ 我可以在迁移文件中手动添加列还是应该生成一个？

Question

Good morning everyone, I am trying to complete the calender app from Codeacademy, and I need to complete the following steps.

Open the migration file in db/migrate/ for the days table, and add the following columns:

• a datetime column called date

Open the migration file in db/migrate/ for the days table, and add the following columns: a datetime column called date Open the migration file in db/migrate/ for events tracks table, and add the following columns:

1. a string column called name
2. a datetime column called from
3. a datetime column called to
4. a string column called location
5. a references column to the Day model

So far, I have added it manually to the migration files like so:

class CreateDays < ActiveRecord::Migration
  def change
    create_table :days do |t|
      t.datetime :date
      t.timestamps
    end
  end
end

class CreateEvents < ActiveRecord::Migration
  def change
    create_table :events do |t|
      t.string :name
      t.datetime :from 
      t.datetime :to 
      t.string :location 
      t.timestamps
      #Not sure how to add references column????
    end
  end
end

However, I am running into an error when I run rake db:migrate, I get no output. Is there supposed to be an output? I have run rake db:migrate --trace and here is the output:

Answer 1

A migration file is like a script which changes your database in some way. It does not store the state of your database.

It will not do anything unless you run it: your database has a special table to keep track of which ones have been run already, called schema_migrations . When you do rake db:migrate you run all scripts in that folder which haven't been run already, according to that table.

So, if you run a script, then change it, then do db:migrate, it won't run it again because it thinks it's been run already. If it did run it again, it would likely blow up because it would be trying to add lots of columns that already exist.

If you define a table in a migration, then later want to add more columns, you can either roll the migration back (which will drop the table), then run it again with the added columns, or write a new migration which just adds the required new columns. The latter approach is usually best.

Answer 2

I assume that you have ran the migrations before. So there is a table named schema_migrations where it stores the migration which has already ran so you cannot re run them. The best way to add new columns to an existing table is to create a new migration like this:

rails g migration add_some_columns_to_events name:string

and name the other columns. And still if you need to do it using the existing migration then what you can do is:

rake db:migrate:down VERSION=<version_of_migration>

and then add up the columns in migration file and run:

rake db:migrate:up VERSION=<version_of_migration>

You can also rollback your last migration and re run the migration using:

rake db:rollback

Hope this helps.

Answer 3

You can only run a migration once - if you've already run the migration, you have two options:

• You can roll back the migration with rake db:rollback , edit it, and then run it again with rake db:migrate , or
• You can generate a new migration and put your changes in it. Then you can run the new migration with rake db:migrate .

Answer 4

Whenever you run rake db:migrate,it runs all the pending migrations using the timestamp which every migration file has ..such as YYYYMMDDHHMMSS_create_products.rb.

Any file which has a migrations greater than the previously run migration timestamp will be picked up during rake db:migrate and then checked whether the changes are present in the db. For example : For a migration file 20080906120001_add_details_to_products.rb ...if you have ran it then all the changes will be added in the db.if you edit it and then run it again then it won't be picked up as timestamp of migration should be grater then previously ran file,which is not. You can manually change the migrations by editing few numbers so that it gets picked up again without creating a new file.

I would recommend create a new one as they are way to maintain and are each migration should be unique.