Size: a a a

2020 December 30

А

Антон in symfony
Konstantin Nosov
зависимость кода миграции от кода приложения. Но если у нас это просто генерация ид, мы можем в миграции ее отдельно написать. Тогда при изменени логики требований в будующем проблем не будет, появится просто новая миграция сверху. В то время как порядок вызова будет детерминиован и конфликтов не будет
И получится, что старая миграция гоняется зря. Вместо консольной команды, которая всегда сгенерирует актуальный набор данных.
источник

i

invariance in symfony
А есть какой-то способ выдернуть сгенереный запрос перед флашем?
источник

i

invariance in symfony
в доктрине
источник

А

Антон in symfony
invariance
А есть какой-то способ выдернуть сгенереный запрос перед флашем?
Лога не хватает? Она их активно пишет
источник

KN

Konstantin Nosov in symfony
Антон
И получится, что старая миграция гоняется зря. Вместо консольной команды, которая всегда сгенерирует актуальный набор данных.
да, но если данных нет она ничего и не сделает, в то время на поиск что в некоторых случаях нужно запустить комманду помоему больше будет потрачено.
источник

AN

Alexander Nazarov in symfony
С консольной командой есть проблема отката миграции. Допустим вы накатили миграцию. Запустили команду. Выпилили команду из проекта. И откатили миграцию. Повторный накат миграции можно выполнить и не иметь уже команду в проекте.
источник

А

Антон in symfony
Konstantin Nosov
да, но если данных нет она ничего и не сделает, в то время на поиск что в некоторых случаях нужно запустить комманду помоему больше будет потрачено.
Makefile
источник

KN

Konstantin Nosov in symfony
Антон
Makefile
выглядит как оверкилл, при наличии встроенных в симфони механизмов сверху симфони городить еще таск раннер
источник

AN

Alexander Nazarov in symfony
То есть откат миграции по идее дропнет всю новую колонку. А накатывание миграции не заполнит новую колонку данными. Что может быть критично
источник

А

Антон in symfony
Konstantin Nosov
выглядит как оверкилл, при наличии встроенных в симфони механизмов сверху симфони городить еще таск раннер
Следить за миграциями лучше?
источник

KN

Konstantin Nosov in symfony
Антон
Следить за миграциями лучше?
они вроде как бы и так есть всегда.
источник

KN

Konstantin Nosov in symfony
Alexander Nazarov
То есть откат миграции по идее дропнет всю новую колонку. А накатывание миграции не заполнит новую колонку данными. Что может быть критично
скорее удаление колонки если и будет то новой миграцией
источник

ВМ

Виктор Монастырев... in symfony
Антон
Следить за миграциями лучше?
зачем за ними следить если они исполняются один раз?
источник

AN

Alexander Nazarov in symfony
Konstantin Nosov
скорее удаление колонки если и будет то новой миграцией
я говорю про down миграции
источник

KN

Konstantin Nosov in symfony
Alexander Nazarov
я говорю про down миграции
не используются
источник

А

Антон in symfony
Виктор Монастырев
зачем за ними следить если они исполняются один раз?
Выше писали, что данные могут поменяться
источник

ВМ

Виктор Монастырев... in symfony
Alexander Nazarov
я говорю про down миграции
очень редко используемый кусок кода, зачастую пишут новую миграцию на откат изменений
источник

DS

Dima Sikorskiy in symfony
А если вдруг нужно получить имя уникальное с другого сервиса внешнего, дергать через миграции при?))))) Это бред
источник

KN

Konstantin Nosov in symfony
Антон
Выше писали, что данные могут поменяться
данные изменится не могут, может поменятся бизнес логика в основном приложении.
источник

KN

Konstantin Nosov in symfony
Dima Sikorskiy
А если вдруг нужно получить имя уникальное с другого сервиса внешнего, дергать через миграции при?))))) Это бред
ну тут же не нужно ходить внешний сервис, если внешний сервис то это таска в кроне на синхронизацию.
Тут разово сгенерировать реф кода уже сущесвтующим пользователям.
источник