Когда (если) консолидировать миграции ActiveRecord?

Ответ 1

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

У других людей есть несколько разные способы сделать это.

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

Это противоречит наилучшей практике: как только вы проверите переход к исходному элементу управления, не изменяйте его. Я делаю редкое исключение, если в нем есть ошибка, но это довольно редко (возможно, 1 из 100). Причина в том, что, когда они вышли в дикую природу, некоторые люди, возможно, их запустили. Они записываются как завершенные в db. Если вы измените их и проверите в новой версии, другие люди не смогут воспользоваться этим изменением. Вы можете попросить людей отменить определенные изменения и повторно запустить их, но это побеждает цель автоматизации. Выполняется часто, это становится беспорядком. Это лучше оставить в покое.

Ответ 2

Я думаю, что есть два вида миграции:

• те, которые вы делали во время разработки/разработки, потому что вы передумали, как должен выглядеть ваш db;

• те, которые вы делали между релизами, отражающие некоторые изменения поведения.

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

О символах против строк: многие утверждают, что в миграциях должны использоваться только строки: символы предназначены для "дескрипторов" для объектов и не должны использоваться для представления имен (в этом случае имена столбцов и таблиц). Это просто стилистическое соображение, но убедил меня, и я больше не использую символы в миграциях.

Я прочитал еще один пример использования строк: "ruby-символы - утечки памяти", а это означает, что при создании символа он никогда не попадает на все время жизни приложения. Это кажется мне совершенно бессмысленным, поскольку все ваши столбцы db будут использоваться в качестве символов в приложении Rails (и ActiveRecord); мигрирующая задача также не будет длиться вечно, поэтому я не думаю, что этот пункт имеет смысл.

Ответ 3

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

Если вы действительно хотите быстро запустить и запустить новую базу данных, вы можете просто загрузить схему с помощью rake db: schema: загрузить RAILS_ENV = your_environment, и если вы хотите быстро установить свою тестовую базу данных, вы можете просто использовать rake db: тест: подготовка

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

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

Ответ 4

Верхняя часть schema.rb объявляет:

# This file is auto-generated from the current state of the database. Instead of editing this file, 
# please use the migrations feature of Active Record to incrementally modify your database, and
# then regenerate this schema definition.
#
# Note that this schema.rb definition is the authoritative source for your database schema. If you need
# to create the application database on another system, you should be using db:schema:load, not running
# all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It strongly recommended to check this file into your version control system.

Я должен одобрить то, что [giorgian] сказал выше о разных миграциях для разных целей. Я рекомендую очистить ориентированные на развитие миграции вместе с другими задачами, которые вы выполняете, когда вы отправляете релиз. Это хорошо работает для меня, для себя и для небольших команд. Конечно, мое основное приложение расположено на вершине и между двумя другими базами данных с их собственными схемами, которые я должен быть осторожен, поэтому мы используем миграцию (а не восстановление схемы) для новой установки, и те, кому нужно выжить в разработке релизов.

Ответ 5

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

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

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

Любой проект зрелых Rails, вероятно, будет иметь от 200 до 1000 миграций. По моему опыту, необычно видеть проект с менее чем 30, за исключением этапа планирования. Каждая модель, в конце концов, обычно нуждается в собственном файле миграции.

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

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

Ответ 6

Вы не должны удалять миграцию. Зачем создавать дополнительную работу?

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

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

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

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