Зачем мне когда-либо хотеть отменить миграцию?

Question

В Rails миграции имеют метод down по умолчанию для отмены миграции. В каком случае я бы хотел отменить миграцию?

Некоторые мысли:

Будь то в процессе разработки или производства, у меня всегда есть моментальный снимок базы данных, к которому я могу вернуться, прежде чем я даже выполню миграцию. Специально для миграций, которые выполняют преобразование данных, я обнаружил, что в большинстве случаев возврат снимка происходит даже быстрее, чем возврат миграции. (Так что я бы никогда не сделал это в спешке!)

Если миграция не удастся выполнить, она либо:

• завершится с ошибкой в ​​нетранзакционной базе данных и, таким образом, оставит базу данных поврежденной или
• с ошибкой произойдет исключение и откат транзакции, поэтому нет необходимости возвращать ее в противном случае.

Если внесенные изменения находятся в производстве (или находятся на поздней стадии разработки) и позже окажутся ошибкой, я исправлю свою ошибку в новой миграции. Я бы не вернул старый. В процессе разработки я бы просто удалил миграцию.

Я также обнаружил, что метод down вводит дополнительный код, в котором я повторяюсь, и, таким образом, может вносить новые ошибки. Это противоречит принципу СУХОЙ.

Так что мне любопытны плюсы, потому что я не могу думать ни о чем.

Answer 1

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

1. Создать миграцию и перейти на нее
2. Поймите, что вам нужно внести изменения
3. Миграция до версии до новой миграции с использованием db: миграция с версией
4. Улучшение / исправление вашей миграции
5. Перезапустить задачу миграции

Ваш метод создания снимков работает нормально. Но рельсы автоматически включают в себя тот же эффект, используя методы «вниз» миграции. Работает со всеми БД, имеет прекрасный вкус

Добавлено:

В отношении производства я согласен с тем, что не требуется перенос миграции. Но иногда случаются ошибки и нужно откатываться назад. Путь перехода вниз дает вам первую и быструю возможность исправить ситуацию в аварийной ситуации во время обновления, которое идет не так.

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

Answer 2

Идея замедления миграции на производстве ужасает меня. Назад, когда предпочтительным способом отката всех миграций был rake db:migrate VERSION=0, я бы делал это все время в разработке. Однако потом я стал параноиком, что, поскольку он был посвящен мышечной памяти, я случайно набрал его на рабочем сервере, когда намеревался просто мигрировать.

Из-за этой паранойи я добавляю следующее ко всем моим методам дауна.

  def self.down
    if Rails.env.production?
      raise ActiveRecord::IrreversibleMigration
    else
      drop_table :foo_bars
    end 
  end 

Таким образом, он все еще работает в разработке, но я не могу случайно сбросить свою производственную базу данных с орбиты, будучи в полусне в 2:00.

Answer 3

Миграция «вниз», используемая для откатов БД, существует, поэтому каждое действие имеет равное и противоположное действие. Разработчик снимает с себя ответственность за поддержание моментальных снимков базы данных и позволяет им использовать код для достижения тех же целей. Как сказал Ларри К, они хороши для таких ситуаций:

• Добавьте столбец базы данных под названием «повторно отправлено», это логическое значение.
• Владелец продукта говорит, что он может повторно отправлять несколько раз, поэтому измените этот столбец как int

Теперь, если у вас 10 или 15 миграций, проще просто написать новую, а не потерять все данные dev в новых таблицах / столбцах, выполнив откат. Однако, если вы только что написали эту миграцию, она будет более чистой и менее загроможденной для отката, изменения миграции и повторного запуска.

Другая чрезвычайно полезная функция откатов заключается в следующем:

• Разработчик 1 имеет свою собственную базу данных разработчиков. Он пишет миграцию и запускает ее.
• Разработчик 1 передает свою миграцию в систему контроля версий
• Разработчик 2 имеет свою собственную базу данных разработчиков. Она пишет миграцию и запускает ее.
• Обновления разработчика 2 из системы контроля версий
• Разработчик 2 пытается запустить миграцию, но не может, поскольку ее локальная БД говорит, что «последняя миграция уже выполнена», так как ее миграция (последняя), технически уже была запущена. Теперь ей нужно откатиться, а затем выполнить db: migrate, чтобы получить все миграции в своей локальной БД.

Answer 4

Если миграция не дала ожидаемого результата, лучше откатить и переписать ее, чем сохранить неудачную миграцию в коде.