Некоторый вопрос о миграциях c enum Laravel. Что там не так?

Question

[JeanPaulBelmondo]

Используется Laravel, хотя в целом, я думаю, без разницы. Есть миграция:

$table->enum('blabla', Model::PRODUCT_TYPES)->default(Model::NEW_PRODUCT_TYPE);

То есть PRODUCT_TYPES и NEW_PRODUCT_TYPE константы модели, массив строк и строка.
Всегда всё прекрасно работало.

Но тут ревьюер пишет:

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

какие такие проблемы со стабильностью могут быть? или это просто тараканы в голове у ревьюера?

Comments

[JhaoDa]

Спросить ревьювера ты не догадался, конечно...

[tukreb]

JhaoDa, а для чего тогда тостер существует? /s

[pLavrenov]

Я так-же делаю как в примере кода и не придумал ситуации в которой это может быть фатально.

[Дмитрий]

pLavrenov, проходит время. Product::TYPES меняется. Какой нибудь тип удаляется, какой нибудь добавляется. Что бы зафиксировать эти изменения прибавляется куча миграций которые старый тип перегоняют в новый. Каков шанс что человек который попробует развернуть у себя проект обнаружит ошибку что миграция не выполняется и что ему с этим делать.

[pLavrenov]

Дмитрий, каждая миграция на изменение enum выполнится просто с одинаковыми параметрами. Да она выполнится 3-5-10 раз (это тоже решается если разбирать мусорку из миграций хотя-бы раз в год), но она выполнится с тем массивом который указан в типах.

[pLavrenov]

Дмитрий, хотя наверн только если поле тип вообще удалят и соответственно массив. Но прежде чем удалят поле будет глобальная зачистка от него

[Дмитрий]

pLavrenov, вы рассматриваете только вариант добавления в мелкой таблице. а я вам говорю про вариант когда у вас удаляется какой то тип, следовательно надо пройтись заменить его в таблице, а если таблица большая то это не сказать что бы такая быстрая и простая задача, и потом удалить из enum. А если проект большой и быстро развивающийся, то таких операций может накопиться вагон. И геммороя можно здесь схлопотать еще больше. Отсюда был сформулирован вывод - не использовать модели в миграциях.

У вас модели всегда работают с последней версией базы данных. А миграции начинаются с 1.

Answer 1

[Дмитрий]

Правильно сказал. Через полгода у вас эту модель удалят. Или изменят. Придёт новый человек и попробует у себя развернуть проект и накатить миграции - получит ошибку. Как ее побороть? Искать в миллионе коммитов как эта модель выглядела?

Правило общее для всех языков и фреймворков. В Гугл вбейте don’t use models in migrations получите ответ.