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

Question

Как я перехожу через итерации в своем приложении * (ы) Я накапливаю миграции. На данный момент существует 48 таких файлов, охватывающих около 24 месяцев деятельности.

Я рассматриваю возможность взять мой текущий schema.rb и сделать это базовым.

Я также рассматриваю возможность удаления (при условии управления исходным кодом, конечно) существующих миграций и создания красивой новой новой миграции из моей моей текущей схемы? Миграции имеют тенденцию напоминать символы, но rake db:schema:dump использует строки: мне все равно?

Это кажется разумным? Если да, то в каком промежутке такое упражнение имеет смысл? Если нет, почему бы и нет?

И я пропустил какую-то (грабли?) Задачу, которая сделает это для меня?

* В моем случае все приложения основаны на Rails, но все, что использует миграции ActiveRecord, похоже, соответствует вопросу.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

Верх схемы.гь заявляет:

# 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's strongly recommended to check this file into your version control system. 

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

Answer 6

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

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

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

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