Обновление схемы Doctrine или миграция Doctrine

Каковы практические преимущества Doctrine Migrations за запуск обновления схемы?

Безопасность

Команда orm:schema-tool:update (doctrine:schema:update в Symfony) предупреждает

Эта операция не должна выполняться в рабочей среде.

но почему это? Конечно, он может удалять данные, но может быть и перенос.

Гибкость

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

Ответ 1

Когда вы используете schema-tool, история изменений базы данных не сохраняется, а в среде производства/промежуточной записи это большой недостаток.

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

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

И даже больше! Вы даже можете описать обратный процесс (миграция down), когда вам нужно отменить изменения, внесенные в вашу миграцию. Предположим, что кто-то где-то сильно полагался на формат поля VARCHAR, и теперь, когда вы изменили структуру, его фрагмент кода работает не так, как ожидалось. Итак, вы запускаете migration:down, и все возвращается. В этом конкретном случае вы просто вернете старый столбец VARCHAR и соедините значения обратно, а затем опустите поля.

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

Кроме того, миграция - это то, что дает другим разработчикам знания вашей команды, когда пришло время обновлять свои схемы. Только с помощью schema-tool ваши товарищи по команде должны будут запускать doctrine:schema:update каждый раз, когда они будут тянуть, потому что они не узнают, действительно ли схема изменилась.

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

Ответ 2

Я думаю, что вы действительно прибивали его к безопасности. С помощью Migrations вы можете вернуться в другое состояние таблицы (так же, как вы можете сделать в Git управлении версиями). С помощью команды обновления схемы вы можете ОБНОВИТЬ только таблицы. В случае сбоя с уже сохраненными данными в этих таблицах журнал не сохраняется. Я точно не знаю, но миграция также не сохраняет данные соответствующей таблицы, которая обновляется? На мой взгляд, это было бы существенно, иначе нет оснований для их использования.

Итак, я лично считаю, что основной причиной использования миграций в производственной среде является безопасность и, возможно, немного гибкость. Безопасность будет победителем здесь, я думаю:)

Надеюсь, что это поможет.

edit: Вот еще один ответ со ссылками на документы Symfony: Безопасно ли использовать миграции doctrine2 в рабочей среде с symfony2 и php