Rails: я обновляю файл миграции, затем запускаю db: migrate, но моя схема не обновляется

Question

Я пытаюсь добавить дополнительное поле в одну из моих таблиц.

Я добавил поле в файл миграции (в папке db \ migrate), затем запустил 'rake db: migrate', который работал без проблем. Мой текстовый редактор даже сказал мне, что мой файл schema.db обновлен и нуждается в обновлении.

Файл схемы не содержит моего нового поля, и любые попытки обратиться к полю из моих представлений с треском проваливаются.

Как мне это сделать? Можно обновить таблицу с дополнительным полем через рельсы без необходимости полного удаления и повторного создания базы данных?

Answer 1

http://guides.rubyonrails.org/migrations.html#changing-existing-migrations

Иногда вы делаете ошибку при написании миграции. Если вы уже запустили миграцию, то вы не можете просто отредактировать миграцию и снова запустить миграцию: Rails считает, что она уже запустила миграцию и поэтому ничего не сделает при запуске rake db: migrate. Необходимо откатить миграцию (например, с помощью rake db:rollback), отредактировать миграцию и затем запустить rake db:migrate, чтобы запустить исправленную версию.

Answer 2

Вы всегда должны создавать новый файл миграции при добавлении / изменении чего-либо в базе данных. Это цель миграций. Файл миграции должен иметь возможность вносить новые изменения и отменять изменения. Таким образом, если что-то пойдет не так или вы передумали, вы можете легко вернуться к предыдущей миграции.

Вам могут помочь следующие разделы ссылок, обозначенные как «Анатомия миграции» и «Написание миграции».

http://guides.rubyonrails.org/migrations.html

Answer 3

Решил свой вопрос ..

По сути, вместо того, чтобы редактировать исходные файлы миграции, созданные при запуске скаффолдинга, вы создаете новый файл миграции только для того, что хотите получить:

http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration

Answer 4

Я сделал то же самое, я хотел изменить имя поля и вместо этого:

class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.string :commenter
      t.text :body

      # this line adds an integer column called `article_id`.
      t.references :article, index: true

      t.timestamps
    end
  end
end

Я изменил

  t.text :body

до

t.text :comment_body

Я пытался сделать рейк

db:migrate

ничего не произошло, так как оно снова пошло в командную строку без какого-либо вывода ..., я посмотрел на переполнение стека и этот велел мне делать рейк

db:migrate:redo

без положенного

== 20141129044056 CreateComments: reverting ===================================
-- drop_table(:comments)
   -> 0.0000s
== 20141129044056 CreateComments: reverted (0.0886s) ==========================

== 20141129044056 CreateComments: migrating ===================================
-- create_table(:comments)
   -> 0.0040s
== 20141129044056 CreateComments: migrated (0.0040s) ==========================

и затем я загрузил свою страницу / контроллер с commenter_body вместо body, и он загрузился отлично.

Я думаю, что это тоже решение того же самого. Я не знаю, есть ли какая-либо проблема в нижележащих работах в модели / DB (я все еще очень плохо знаком с RoR, мой третий день фактически ...)

Answer 5

Я смог восстановить мою схему с последними миграциями, запустив rake db:schema:dump

Answer 6

После того, как вы выполните rake db: migrate, вы снова не можете добавить столбец в этот файл. Вам нужно сгенерировать новый файл миграции, используя rails. !

Answer 7

Не знаю, применимо ли это, но оно того стоит. Прямо из " Agile Development с Rails, 3-е издание ":

Иногда эта таблица schema_migrations может вызвать у вас проблемы. Например, если вы создаете перенести исходный файл и запустить db:migrate перед добавлением в файл каких-либо операторов, определяющих схему, база данных будет думать, что она была обновлена, а таблица информации схемы будет содержать новую версию число.
Если вы затем отредактируете этот существующий файл миграции и снова запустите db:migrate, Rails не будет знать, применить ваши новые изменения. В этих условиях часто проще всего удалить базу данных, заново создать и перезапустите миграцию (и).