Как удалить скрипт из существующего миграционного файла rails

Question

Я вытащил новые изменения из git, в этих новых изменениях есть файл миграции,

def change
  add_column :users, :activated_at, :datetime
  User.all.each do |user|
   user.update(activated_at: user.updated_at)
 end    
end

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

, но если я просто хочу удалить сценарий, например user.update(activated_at: user.updated_at), нужно ли создавать еще одну миграцию или просто удалить сценарий из миграции.

примечание: я не хочу удалять столбец activ_at, я просто хочу удалить скрипт

Answer 1

Мой ответ немного более нюансированный.Короче говоря, вы спрашиваете: можете ли вы изменить миграцию, которая уже запущена?В общем, я бы советовал против этого.В вашем случае это также зависит от того, что должно происходить с полем activated_at, я могу себе представить, что оно будет установлено только после того, как пользователь будет «активирован» (что бы это ни значило в контексте вашего приложения).Так в таком случае: установить его на updated_at неверно и должно быть "не установлено"?Или установить по-другому?Так что это потребует миграции в любом случае.Или, также возможно: миграция еще не запущена, например, на вашем производственном сервере, и выполнить миграцию, как это, было бы очень трудно отменить хорошим способом (ну, в этом случае это было бы просто - установить активирован-снова в ноль)), то непременно адаптируйте миграцию, зафиксируйте и после развертывания запустите миграцию лучше Но ... вам придется вручную восстанавливать / исправлять ситуацию на всех машинах, на которых выполнялась миграция , выполнялась ли (ваша машина, ваши коллеги, платформы для промежуточного тестирования? ...)

Итакчтобы помочь вам с процессом принятия решения

• , если вы работаете в команде, и товарищи по команде проверили ваш код и запустили миграции, используйте новую миграцию, чтобы исправить ее
• , есливы развернули на любом сервере (тестирование / подготовка / производство), который в противном случае вам пришлось бы исправить, добавьте новую миграцию, чтобы исправить ее
• , если вы не передали свой код на master (весь код осталсялокально), адаптируйте миграцию по желанию: P

В качестве отступления: я видел разработчиков, которые так хотят иметь только «идеальный» код в git, они будут использовать все опции, которые предлагает git для очисткиКод: вернитесь в историю, сквош коммитов, и я должен признать, что результат очень ясен.Это очень заманчиво и понятно, но имхо мы теряем информацию (как мы сюда попали и почему?).Точно так же заманчиво иметь чистые и минимальные миграции, но лично я считаю, что нет ничего постыдного в том, что мерзавцы и ваши миграции "показывают" растущее понимание проблемной области.Я думаю, что это одна из причин, по которой это называется «разработкой»: сборка программного обеспечения - это очень итеративный процесс, который постоянно меняется, и ваш код (git / history) и миграции могут это отражать.Приношу свои извинения, если эта последняя часть слишком мета и субъективна.

Answer 2

Вы можете просто удалить код и зафиксировать в главной ветви.

Для систем, на которых выполняется эта миграция, вы можете запустить rake task , чтобы запустить все, что вы хотите откатить (т.е. установитьactivated_on до нуля).Или вы можете запустить консоль rails для установки nil.

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