DS
Зачем что-то менять в миграциях, создавать новую с новой логикой.
разве в миграциях должна быть бизнес логика ?
Size: a a a
2020 December 30
ВМ
да, команду нужно запустить только один раз
и при чем результат команды ( uuid ) в базе нужен до того, как код начнет его использовать
k
Миграции
я про ситуацию, когда миграция зависит от приложения самого. См. пример с uuid. Используем какой-то код в миграции, а потом он поменялся и тогда миграции не запускаются.
AN
Все верно, если вы используете логику каких то сервисов, то с изменением сервисов придется следить за миграцией. Чтобы они без проблем накатывались и откатывались
ВМ
и при чем результат команды ( uuid ) в базе нужен до того, как код начнет его использовать
если это верно, то только миграция
иначе разбивка выкатки фичи на несколько итераций с поддержкой обратной совместимотси и т.д.
иначе разбивка выкатки фичи на несколько итераций с поддержкой обратной совместимотси и т.д.
ПГ
разве в миграциях должна быть бизнес логика ?
Нет, то там какой то разговор, что что-то менять. Раз мы один тип юид можем записать через миграцию, почему тогда при смене этого типа юида нельзя это делать так же через миграции. Я правда вообще не совсем понял эту тему с сменой uuid
KN
Все верно, если вы используете логику каких то сервисов, то с изменением сервисов придется следить за миграцией. Чтобы они без проблем накатывались и откатывались
получается проблемы не будет если в миграции я не буду дергать уже существующий сервис, а напишу изолированный код для прохода по бд и генерации кодов нужным мне алгоритмом
ПГ
Все верно, если вы используете логику каких то сервисов, то с изменением сервисов придется следить за миграцией. Чтобы они без проблем накатывались и откатывались
А вот это звучит как аргумент весомый
AN
получается проблемы не будет если в миграции я не буду дергать уже существующий сервис, а напишу изолированный код для прохода по бд и генерации кодов нужным мне алгоритмом
ну судя по тому что вы говорите, вы этот алгоритм уже имеете в коде приложения. Вы будете пладить дубли кода!?
KN
Нет, то там какой то разговор, что что-то менять. Раз мы один тип юид можем записать через миграцию, почему тогда при смене этого типа юида нельзя это делать так же через миграции. Я правда вообще не совсем понял эту тему с сменой uuid
на самом деле там не uid, а к примеру https://hashids.org/php/ который обратим
KN
ну судя по тому что вы говорите, вы этот алгоритм уже имеете в коде приложения. Вы будете пладить дубли кода!?
если этот алгоритм внутри кода, то код может меняться. выглядит логичным в миграции положить копию которая не будет зависеть от кода в основном приложении
DS
Нет, то там какой то разговор, что что-то менять. Раз мы один тип юид можем записать через миграцию, почему тогда при смене этого типа юида нельзя это делать так же через миграции. Я правда вообще не совсем понял эту тему с сменой uuid
я за консоль команду или тому подобному. сегодня нам нужно раз сделать генерацию, завтра это требование изменилось. миграции созданы для управления структурой, но не для управления данными. + миграции это немножко другой уровень приложения
ПГ
я за консоль команду или тому подобному. сегодня нам нужно раз сделать генерацию, завтра это требование изменилось. миграции созданы для управления структурой, но не для управления данными. + миграции это немножко другой уровень приложения
+
AN
если этот алгоритм внутри кода, то код может меняться. выглядит логичным в миграции положить копию которая не будет зависеть от кода в основном приложении
В таком кейсе вам лучше разделить на команду, потому что при накатывании миграций с нуля, у вас не будет данных которые вам нужно менять.
KN
В таком кейсе вам лучше разделить на команду, потому что при накатывании миграций с нуля, у вас не будет данных которые вам нужно менять.
ну при накатывании с нуля тогда просто количество строк для прохода будет 0. И на самом деле мы из дампа проект стартуем
KN
если этот алгоритм внутри кода, то код может меняться. выглядит логичным в миграции положить копию которая не будет зависеть от кода в основном приложении
то есть вот это вопрос на самом деле
KN
зависимость кода миграции от кода приложения. Но если у нас это просто генерация ид, мы можем в миграции ее отдельно написать. Тогда при изменени логики требований в будующем проблем не будет, появится просто новая миграция сверху. В то время как порядок вызова будет детерминиован и конфликтов не будет
AN
Ну вот это и плохо, что вы для миграции хотите собрать свой код который ей необходим. Там же можно будет захотеться еще свой composer.json положить и т.п.
KN
но если я втяну код основного продукта мутация более не будет идемпотентной.