Перебазировать миграции Rails в долгосрочном проекте

Question

В котором я имею в виду «перебазирование» в словаре, а не определение git ...

У меня есть большой и долго работающий проект Rails, который имеет около 250 миграций, и все это становится громоздким для управления.

Тем не менее, мне нужна база для очистки и восстановления моей базы данных при выполнении тестов. Поэтому данные, содержащиеся в них, важны.

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

Очевидно, что я могу использовать rake schema: dump - но мне действительно нужен способ, чтобы db: migrate сначала загрузил схему, а затем запустил остальные миграции.

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

Answer 1

В общем, вам не нужно очищать старые миграции.Если вы используете db: мигрировать с нуля (без существующей базы данных), Rails использует db / schema.rb для создания таблиц вместо выполнения каждой миграции.В противном случае выполняется только миграция, необходимая для обновления с текущей схемы до последней.

Если вы все еще хотите объединить миграции до заданной точки в одну, вы можете попробовать:

• выполнить миграцию с нуля до целевой схемы, используя rake db:migrate VERSION=xxx
• , сбросить схему с помощью rake db:schema:dump
• удалить миграции с самого начала до версии xxx и создать однуновая миграция с использованием содержимого db / schema.rb (поместите операторы create_table и add_index в метод self.up новой миграции).

Убедитесь, что выбран один из старых номеров версий миграции дляваша новая совокупная миграция;в противном случае Rails попытается применить эту миграцию на вашем производственном сервере (что приведет к стиранию существующих данных, поскольку операторы create_table используют: force⇒true).

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

Answer 2

Чтобы автоматизировать объединение (или сжатие) миграций, вы можете использовать Squasher gem

Просто установить

gem install squasher

И запустить с датой, имиграции до этой даты будут объединены:

squasher 2016 # => Will merge all migration created before 2016

Подробнее в README

Answer 3

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

Еще одна простая помощь в восстановлении ваших таблиц состоит в том, чтобы выделить отдельное окно терминала для одного комбинированного оператора:

rake db: drop db: create db: schema: load db: fixtures:load

Каждый раз, когда вам нужно перестроить и заново заполнить ваши таблицы, стрелка вверх и нажатие клавиши возврата выполнят эту обычную работу.Если в операторах выполнения SQL нет конфликта и если у вас нет дальнейших миграций, когда проект находится в состоянии разработки, операторы SQL будут выполняться, возможно, в два раза быстрее, чем синтаксис Ruby.Например, наши таблицы перестраиваются и переполняются за 20 секунд, тогда как синтаксис Ruby увеличивает процесс до более чем 50 секунд.Если вы ожидаете обновления этих данных для выполнения дальнейшей работы (особенно много раз), это имеет огромное значение в рабочем процессе.