KN
как раз разовость и наводит на идею что миграции тут правильное решение. Запуск команды нужно тоже ведь приурочить к определенной версии бд. Что не есть тривиальной задачей
Size: a a a
2020 December 30
ВМ
данные изменится не могут, может поменятся бизнес логика в основном приложении.
вам нужно накатить это всего один раз
Команда, как по нме, излишня потому что её постоянно дергать не будут
Да и удалят её скорее всего спустя неделю
Учитываю что вы накатываете дам базы, то толку от истории миграций тоже нет ни какого
как следствие код внутри миграции в данном случае вполне себя оправдываем, с моей точки зрения
Команда, как по нме, излишня потому что её постоянно дергать не будут
Да и удалят её скорее всего спустя неделю
Учитываю что вы накатываете дам базы, то толку от истории миграций тоже нет ни какого
как следствие код внутри миграции в данном случае вполне себя оправдываем, с моей точки зрения
KN
вам нужно накатить это всего один раз
Команда, как по нме, излишня потому что её постоянно дергать не будут
Да и удалят её скорее всего спустя неделю
Учитываю что вы накатываете дам базы, то толку от истории миграций тоже нет ни какого
как следствие код внутри миграции в данном случае вполне себя оправдываем, с моей точки зрения
Команда, как по нме, излишня потому что её постоянно дергать не будут
Да и удалят её скорее всего спустя неделю
Учитываю что вы накатываете дам базы, то толку от истории миграций тоже нет ни какого
как следствие код внутри миграции в данном случае вполне себя оправдываем, с моей точки зрения
я вот тоже к такому решению склонен, осталось @DimaSikorskiy согласится :)
KN
но к чести сказать я не ожидал что вообще кто-то будет менять данные при помощи команд, для меня такой подход изначально дико звучал (но похоже многие его применяют)
AN
Миграция в которой существует бизнес логика это не айс. Все что мы хотим делать в миграции должно быть на SQL.
KN
да, но увы сделать генерацию кодов для mariadb не представляется возможным в хранимке (хотя вот в PG можно сделать https://hashids.org/postgresql/)
DS
я вот тоже к такому решению склонен, осталось @DimaSikorskiy согласится :)
конечно не соглашусь, генерация данных может происходить разными путями. + логика генерации будет использоваться по коду наверное 100%. как пример получить уникальный айди с внешнего сервиса. в миграции вызвать апи сервис и обновлять ентити - это фигня полная.
AN
Если вы изолируете генерацию кода как то вменяемо то это еще норм. Но если ваша генерация кода это что то внутри приложения то это не очень
ВМ
но к чести сказать я не ожидал что вообще кто-то будет менять данные при помощи команд, для меня такой подход изначально дико звучал (но похоже многие его применяют)
очень редкие кейсы по подготовке данных для новой версии приложения
В основном в миграция только изменения структуры базы данных, но ни как не структуры данных в базе
В основном в миграция только изменения структуры базы данных, но ни как не структуры данных в базе
KN
конечно не соглашусь, генерация данных может происходить разными путями. + логика генерации будет использоваться по коду наверное 100%. как пример получить уникальный айди с внешнего сервиса. в миграции вызвать апи сервис и обновлять ентити - это фигня полная.
у нас нет необходимости брать ид из внешнего кода. В нашем случае код рефера это фактически производная из userid, цель которой быть уникальной в рамках бд пользователей
AN
эмммм.... Если вы собираетесь в миграции использовать Entity и EntityManager то это явно не правильно
KN
эмммм.... Если вы собираетесь в миграции использовать Entity и EntityManager то это явно не правильно
да, то есть нужно делать это прямым запросом в бд
ВМ
эмммм.... Если вы собираетесь в миграции использовать Entity и EntityManager то это явно не правильно
поддерживаю
KN
поддерживаю
то есть итого:
использовать php код в миграциях можно, но есть ряд но:
1. код миграции должен быть изолирован от кода приложения
2. в коде миграции нельзя пользоваться Entutyes и иными благами ORM т.к. они внешние по отношению к миграции
3. это оправданно только в том случае если это действительно разовое обновление данных
использовать php код в миграциях можно, но есть ряд но:
1. код миграции должен быть изолирован от кода приложения
2. в коде миграции нельзя пользоваться Entutyes и иными благами ORM т.к. они внешние по отношению к миграции
3. это оправданно только в том случае если это действительно разовое обновление данных
DS
у нас нет необходимости брать ид из внешнего кода. В нашем случае код рефера это фактически производная из userid, цель которой быть уникальной в рамках бд пользователей
миграции не должны знать, как генерировались данные - даже разово) эти данные могут быть сделанные кодом, а могут и с помощью внешнего сервиса, а может быть и комбинация
ВМ
миграции не должны знать, как генерировались данные - даже разово) эти данные могут быть сделанные кодом, а могут и с помощью внешнего сервиса, а может быть и комбинация
а если твоему приложения к началу его работы УЖЕ нужны обновленные данные? )
KN
миграции не должны знать, как генерировались данные - даже разово) эти данные могут быть сделанные кодом, а могут и с помощью внешнего сервиса, а может быть и комбинация
это слишком общий случай, в жизни многие преобразования данных являются чистой функцией, если миграция является оной то она может и менять данные.
AN
миграции не должны знать, как генерировались данные - даже разово) эти данные могут быть сделанные кодом, а могут и с помощью внешнего сервиса, а может быть и комбинация
может быть какие то абстрактные миграции в вакуме этого не должны знать. Но вы же говорите про конкретные миграции в важем проекте?
KN
может быть какие то абстрактные миграции в вакуме этого не должны знать. Но вы же говорите про конкретные миграции в важем проекте?
да, но тут можно сделать обобщение - генерация refcode это чистая функция, похожая на генерацию хеша
DS
а если твоему приложения к началу его работы УЖЕ нужны обновленные данные? )
дока или написан механизм деплоя. (запуска приложения)