Обновление схемы доктрина или учение миграций
Каковы практические преимущества миграции доктрин по сравнению с простым запуском обновления схемы?
Безопасность?
Команда orm:schema-tool:update (doctrine:schema:update в Symfony) предупреждает
Но почему это происходит? Конечно, он может удалять данные, но и миграция тоже.Эта операция не должна выполняться в рабочей среде.
Гибкость?
Я думал, что смогу адаптировать свои миграции, чтобы добавить такие вещи, как значения по умолчанию столбцов, но это часто не так работайте так, как учение заметит несоответствие между схемой и кодом на следующем различии и потопчется над вашими изменениями.
3 ответа:
Когда вы используете
Предположим, что у вас сложная структура базы данных в живом проекте. И в следующем наборе изменений вы должны как-то изменить базу данных. Например, контактные телефоны пользователей должны храниться в другом формате, не в видеschema-tool, история изменений базы данных не сохраняется, и в производственной/промежуточной среде это является большим недостатком.VARCHAR, а в виде трех столбцовSMALLINTдля кода страны, кода города и номера телефона.Ну, это не так. так трудно придумать запрос, который бы извлекал текущие данные, разделял их на три значения и вставлял обратно. Именно тогда в игру вступают миграции: вы можете создать свои новые поля, затем выполнить преобразования и, наконец, удалить поле, в котором раньше хранились данные.
И даже больше! Вы даже можете описать обратный процесс (миграцию
down), когда вам нужно отменить изменения, внесенные в вашу миграцию. Предположим, что кто-то где-то сильно полагался на формат полеVARCHAR, и теперь, когда вы изменили структуру, его часть кода работает не так, как ожидалось. Итак, вы запускаетеmigration:down, и все возвращается обратно. В этом конкретном случае вы просто вернете старый столбецVARCHARи объедините значения обратно, а затем удалите поля.Инструмент миграции доктрины в основном делает большую часть работы за вас. Когда вы различаете свою схему, она генерирует все необходимые
upиdown, поэтому единственное, что вам нужно сделать, это обработать данные, которые может быть поврежден при применении миграции.Кроме того, миграции-это то, что дает другим разработчикам в вашей команде знания о том, когда пришло время обновить свои схемы. С помощью только
schema-toolваши товарищи по команде должны были бы запускатьdoctrine:schema:updateкаждый раз, когда они тянут, потому что они не знали бы, действительно ли схема изменилась.При использовании миграции вы всегда видите, что в папке миграции есть некоторые обновления, что означает, что вам нужно обновить схему.
Я думаю, что вы действительно прибили его на безопасность. С помощью миграции вы можете вернуться в другое состояние таблицы (так же, как это можно сделать в Git version control). С помощью команды schema update можно обновить только таблицы. Там нет журнала, чтобы вернуться назад в случае сбоя с уже сохраненными данными в этих таблицах. Я точно не знаю, но разве миграция не сохраняет также данные соответствующей таблицы, которая обновляется? Это было бы существенно, на мой взгляд, иначе нет большая причина использовать их.
Так что да, я лично считаю, что главная причина использования миграции в производственной среде-это безопасность и, возможно, некоторая гибкость. Безопасность была бы победителем здесь, я думаю:)
Надеюсь, это поможет.
Edit: вот еще один ответ со ссылками на Symfony docs: безопасно ли использовать миграции doctrine2 в производственной среде с symfony2 и php