Не совсем понимаю вашу проблему, но я пытаюсь немного объяснить откат.
Вы выполняете откат, если хотите отменить изменения соответствующей миграцией. Это означает, что база данных будет изменена, а также ваш schema.rb будет автоматически восстановлен. Когда вы делаете это, вероятно, вы хотите удалить ссылочный код тоже. Например, если вы удалили поле из модели, возможно, вы не хотите ссылаться на этот атрибут в своем коде. Если вы попытаетесь получить доступ, вы получите неопределенный атрибут исключение. Вот и все.
Откат может стать немного громоздким, например, если вы ранее создали некоторые миграции модели 10 и хотите изменить некоторые поля. Лучше создать новую миграцию и изменить ее там, а не откатываться на соответствующую миграцию.
Обновление 1
Прочитайте ваше обновление, и я думаю, вы не используете главное преимущество миграции, гибкость.
Но ваше решение дает больше обзора ситуации с базой данных. Если вы хотите сделать это, я предлагаю следующие шаги по порядку.
- Откат к соответствующей миграции. (
rake db:migrate VERSION=XXX, мне нравится больше rake db:rollback STEP = 2 например, откат 2 миграции, STEP необязательно)
- Внесите изменения
- Перенесите базу данных, чтобы обновить все таблицы, и перейдите к текущей версии миграции. (
rake db:migrate)
Эта функция не влияет на ваши модели или что-то в этом роде, просто изменяет файл миграции, восстанавливает ваш schema.rb и меняет структуру базы данных, ничего больше. Не может выполнить откат кода, как с системой контроля версий, и на самом деле не имеет смысла делать что-то подобное. Вы должны позаботиться о том, чтобы не использовать удаленные поля. Rails имеет автоматическое отображение между полями базы данных и атрибутами модели, например, если в вашей таблице comment есть user_id, вы можете назвать его как атрибут вашей модели, comment_instance.user_id.
Надеюсь, что это имеет смысл.