А подскажите пожалуйста как мне это реализовать лучше. Я в юзкейсе открываю транзакцию, потом хожу в каждый репозиторий удаляю, потом в юзкейсе вызываю флаш и закрываю транзакцию?
Или флаш в каждом репозитории делать?
Если делаете через колбэк транзакцию, можно не флашить
Павел
Павел
у меня в каждой репке персист+флуш
В этом подходе есть одно "но" проблемное, что uow в доктрине глобальный. Поэтому вызывая флаш в репо одной сущности, сохраняются другие, что как бы не слабый такой сайд эффектик
Павел
не совсем корректно с точки зрения логики: репа должна быть абстракцией над хранилищем, но...
Есть еще другое рассмотрение логики:
Что репо это абстракция над коллекцией в памяти приложения, а не абстракция над бд, а "флаш" сброс состояния приложения в персистент. Что принципе уже звучит не так уж и плохо
Павел
Потому что с точки зрения аппки, мы как раз не знаем, что стоит за репо: БД, память, или что то другое, для нас это коллекция их которой бы забираем сущности
Павел
Но если рассматривать "как сделать персистент, который не зависел бы с uow он или нет", то не должно быть никакого флаша на уровне апп, т.е. вне репозитория.
В общем нет какого то прям однозначного ответа, кому что ближе. Но имхо, зачем смотреть на что то потенциальное и в сравнении, если оно идет в разрез текущих технологий и вносит свои ньюансы.
Например можно сделать транзакцию над кучей флашей в репозиториях, но это открытие закрытие сейвопинтов, что доп задачи для БД
Вадим
а подскажите пож как отключить события доктрины в тестовой среде
Юра
Может лучше твои листенеры отключить в тестовой среде?
Юра
Я не уверен что можно отключить доктрин события
Вадим
Может лучше твои листенеры отключить в тестовой среде?
я согласен! Подскажите пожалуйста как?
они сейчас автовайрятся
Юра
я согласен! Подскажите пожалуйста как?
они сейчас автовайрятся
Ну в моем случае так как я делаю микробандлами апку то я бы просто бандл вырубил в тесте. В твоём случае нужно подумать
Юра
Symfony\Component\DependencyInjection\Attribute\When
Юра
#[When('<env>')]
Юра
Попробуй так
Dmitriy
есть ключик debug, как-то так называется
Михаил
на сколько я помню он в основном отключает логирование sql запросов и запуск дебаг листенерова
Вадим
А так можно? Можно!
Это нормально? Это нормально!
А если осудят? Да похуй
а если у меня сложный юзкейс который вызывает другие юзкейсы, в каждом вызываемом юзкейсе флашится будет и потом ещё в основном? Это осудительно?
Михаил
а если у меня сложный юзкейс который вызывает другие юзкейсы, в каждом вызываемом юзкейсе флашится будет и потом ещё в основном? Это осудительно?
вообще каждый юзкейс должен быть единицей работы.
Вот я до сих пор не знаю правильно ли делать следующие
— юзкейс А
— работа А
— работа А
— вызов юзкейс Б
— — работа Б
— — работа Б
— работа А
вот если в таком случае флашить изменения в юзкейсе б, то улетят и изменения юзкейса А
тут 3 варианта
1) вложенные транзакции
2) Юзкейсы не должны быть вложенными а должны идти цепочкой
3) юзкейсы не должны вызывать другие юзкейсы (а что тогда? доменные сервисы? бублирование?)
Михаил
2 и 3 сложновыполнимое
1 - очень явное и придётся прям в юзкейсе снова показывать этот отвратительную коллбек транзакцию или вызовы функций по открытию и закрытию
Вадим
вообще каждый юзкейс должен быть единицей работы.
Вот я до сих пор не знаю правильно ли делать следующие
— юзкейс А
— работа А
— работа А
— вызов юзкейс Б
— — работа Б
— — работа Б
— работа А
вот если в таком случае флашить изменения в юзкейсе б, то улетят и изменения юзкейса А
тут 3 варианта
1) вложенные транзакции
2) Юзкейсы не должны быть вложенными а должны идти цепочкой
3) юзкейсы не должны вызывать другие юзкейсы (а что тогда? доменные сервисы? бублирование?)
ви сейчас скажете что я ларавельщик
но отчего не отправить во вложенный кейс $flush = false
и оно не будет флашить
Вадим
или я никак не пойму глобальной философии какойто
Михаил
ви сейчас скажете что я ларавельщик
но отчего не отправить во вложенный кейс $flush = false
и оно не будет флашить
ну просто этот параметр не относится к бизнес логике
а лишний параметр заставляет лишний раз думать и возможно даже открывать юзкейс
плюс юзкейс может быть вызван отдельно от другого юзкейса, короче круто конечно но не в кайф
Вадим
2) если у меня кейс А подразумевает использование кейса Б то как их можно вызывать последовательно когда одно часть другого
The Ant
а если у меня сложный юзкейс который вызывает другие юзкейсы, в каждом вызываемом юзкейсе флашится будет и потом ещё в основном? Это осудительно?
Если не боишься, что из-за этой чехарды тебя кто-то проклянет, когда будет искать тяжело уловимые баги, то пофигу наверное.
The Ant
Ну или сам себя...
Михаил
Если не боишься, что из-за этой чехарды тебя кто-то проклянет, когда будет искать тяжело уловимые баги, то пофигу наверное.
Причём как я говорил про пример с тем, когда мы вызываем логику в ивент листенере - юзкейз может вызывать другой юзкейс ненамеренно.
Так что не достаточно просто обернуть всё в новомодные паттерны - важно еще навести порядок в потоке управления и потоке данных
Павел
вообще каждый юзкейс должен быть единицей работы.
Вот я до сих пор не знаю правильно ли делать следующие
— юзкейс А
— работа А
— работа А
— вызов юзкейс Б
— — работа Б
— — работа Б
— работа А
вот если в таком случае флашить изменения в юзкейсе б, то улетят и изменения юзкейса А
тут 3 варианта
1) вложенные транзакции
2) Юзкейсы не должны быть вложенными а должны идти цепочкой
3) юзкейсы не должны вызывать другие юзкейсы (а что тогда? доменные сервисы? бублирование?)
Проблема втом, что цепочка может быть не всегда выполнима. Когда один модуль, зависит от выполнения другого.
И правильно вы сказали про ивенты, что имеет тот же самый эффект. Но тот же самый эффект могут иметь саги, ивенты и сабскрайберы других сервисов.
Павел
а если у меня сложный юзкейс который вызывает другие юзкейсы, в каждом вызываемом юзкейсе флашится будет и потом ещё в основном? Это осудительно?
Чем больше вложенности тем сложнее, по возможности надо этого избегать
Михаил
Проблема втом, что цепочка может быть не всегда выполнима. Когда один модуль, зависит от выполнения другого.
И правильно вы сказали про ивенты, что имеет тот же самый эффект. Но тот же самый эффект могут иметь саги, ивенты и сабскрайберы других сервисов.
согласен. Но вот делайть пайплайны как то всегда получалось (возможно кстати пайплайны деют больший оверхед в некоторых ситуациях, но их атомарность и последовательность мне очень нравится)
Павел
@vadbard Если у вас модульная структура, то тут или ивенты или прямые вызовы. Т.е. ну никак от этой вложенной чахорды не избавиться между модулями.
Внутри модуля лучше самого себя не вызывать,а вынести в сервис так уменьшится вложенность
Если не модульная, то просто разнесите все по каким то блокам, а уже юзкейсы эти блоки будут вызывать в той или иной последовательности без вложенности.
Павел
согласен. Но вот делайть пайплайны как то всегда получалось (возможно кстати пайплайны деют больший оверхед в некоторых ситуациях, но их атомарность и последовательность мне очень нравится)
Что такое в вашей реализации пайплайн и работаете ли вы с модулями?
Павел
Просто если у вас модуль, то вы из одного модуля вызываете экшен (чтение или запись) другого, а что внутри этого экшена - не знай, может там цепочка из 10 вызовов
Михаил
Хорошо что напомнили про саги.
Возможно сага один из отличнийших способов делать сложную транзакцию из множества шагов (и даже сделать распределённую транзакцию). И в случае ошибки взять и откатить её, но оно требует дополнительных доработок в системе.
Но это речь уже не про доктрину.
Павел
Хорошо что напомнили про саги.
Возможно сага один из отличнийших способов делать сложную транзакцию из множества шагов (и даже сделать распределённую транзакцию). И в случае ошибки взять и откатить её, но оно требует дополнительных доработок в системе.
Но это речь уже не про доктрину.
Опять же да, саги, процесс который из цепочки и может вполне быть не линейным, а так же на ивенты саги могут быть подписаны другие сабскрайберы в теории
Михаил
Просто если у вас модуль, то вы из одного модуля вызываете экшен (чтение или запись) другого, а что внутри этого экшена - не знай, может там цепочка из 10 вызовов
Нет, пайплайн вызывает юзкейсы по очерёдности. Юзкейсы не знают что они являются цепочкой чего-то большего.
Михаил
Опять же да, саги, процесс который из цепочки и может вполне быть не линейным, а так же на ивенты саги могут быть подписаны другие сабскрайберы в теории
вот я стараюсь так не делать.
всё пытаюсь делать плоским и предсказуемым
Павел
Нет, пайплайн вызывает юзкейсы по очерёдности. Юзкейсы не знают что они являются цепочкой чего-то большего.
Да, это хороший кейс, когда юзкейсы не зависят от данных друг друга. Т.е. лучше в какую то плоскость положить их, чем друг в друга.
Павел
Ну и это более вариативно
Павел
Т.е. как раз пайплайн и есть юзкейс, который вызывает какие то экшены
Павел
Юзкейс над юзкейсами)
Михаил
Только вот не понятно на каком слое находятся пайплайны.
Так как контроллер может запустить юзкейс, а может запустить пайплайн который запустит юзкейс.
Куда и как это прятать, как это объяснять - я хз, просто делаю вид что так и надо)
Павел
Тоже задавался таким вопросом, что ощущение что юзкейсы то никакие не юзкейсы, как мы их описываем
Павел
Павел
Что регистрация - это и есть юзкейс, который вызывает какие то "создать юзера", "создать покупателя", "создать что то еще". А не "создать юзера" - юзкейс в модуле авторизации
Павел
Т.е что есть какой то слой, который жонглирует контрактами модулей, и этот слой и есть слой юзкейсов какой то
Павел
Куда можно положить синхронные пайплайны, и например асинхронные саги
Михаил
Вообще для меня юзкейс - это некий спектакль. Он берёт актёров, декорации и показывает представление.
Представление о регистрации пользователя
Представление о написании нового поста
Внутри использую доменные сервисы, доменные сущности итд итп
Технически пайплайн (или сага) про то же самое.
Только там не одно представление а несколько последовательных историй:
1) Представление о регистрации пользователя
2) Представление о создании дашборда для новосозданного пользователя
3) Представление о отсылки письма с поздравлениями для новосозданного пользователя
Павел
Вообще для меня юзкейс - это некий спектакль. Он берёт актёров, декорации и показывает представление.
Представление о регистрации пользователя
Представление о написании нового поста
Внутри использую доменные сервисы, доменные сущности итд итп
Технически пайплайн (или сага) про то же самое.
Только там не одно представление а несколько последовательных историй:
1) Представление о регистрации пользователя
2) Представление о создании дашборда для новосозданного пользователя
3) Представление о отсылки письма с поздравлениями для новосозданного пользователя
Ну просто регистрация пользователя уже представление для нескольких модулей
Павел
Но в целом примерно так же смотрю
Вадим
привет!
Подскажите пожалуйста по удалению связанных сущностей.
Вот у меня есть Task и у неё Comments, классека OneToMany. Есть foreign key.
Удаляем таску, надо чтобы удалились комменты. Что мне написать?
1) orphanRemove:true у таски?
2) cascade: ['remove'] у таски?
3) Просто удалять Task а комменты сами удалятся?
4) Удалить комменты сперва, а потом таску?
5) Скаффолдер при создании сущности со связью OneTоMany прописывает метод removeComment(Comment $comment){} и там сперва делает $comment->setTask(null)
Нужно его использовать?
Сори за сумбур но я ваще запутался
Вадим
Orphan Removal
If an Entity of type A contains references to privately owned Entities B then if the reference from A to B is removed the entity B should also be removed, because it is not used anymore.
Подскажите пожалуйста что значит "удалить ссылку"?
Viktor
Orphan Removal
If an Entity of type A contains references to privately owned Entities B then if the reference from A to B is removed the entity B should also be removed, because it is not used anymore.
Подскажите пожалуйста что значит "удалить ссылку"?
Cascade remove работает на уровне базы данных.
Orphan Removal работает на уровне ORM.
Если у вас orphan removal = true, то если вы с помощью доктрины делаете удаление какой-то сущности (с помощью метода remove($entity), то связанные с этой сущностью другие сущности также удалятся. За этим проследит сама доктрина.
Это если очень кратко)))
Вадим
Cascade remove работает на уровне базы данных.
Orphan Removal работает на уровне ORM.
Если у вас orphan removal = true, то если вы с помощью доктрины делаете удаление какой-то сущности (с помощью метода remove($entity), то связанные с этой сущностью другие сущности также удалятся. За этим проследит сама доктрина.
Это если очень кратко)))
это onDelete: cascade Вы про это наверное
Вадим
Cascade remove работает на уровне ОРМ
Вадим
нет
https://www.doctrine-project.org/projects/doctrine-orm/en/3.2/reference/working-with-associations.html#transitive-persistence-cascade-operations
Вадим
тут говорят что да
Михаил
Cascade remove работает на уровне ОРМ
каскад - это на уровне бд
орфан (сирота) это удаление сущностей с которыми есть связь, но на них никто не ссылается
Вадим
Viktor
https://gist.github.com/pylebecq/f844d1f6860241d8b025
Вадим
каскад - это на уровне бд
орфан (сирота) это удаление сущностей с которыми есть связь, но на них никто не ссылается
вот что значит "связь" в этом контексте?
Viktor
вот что значит "связь" в этом контексте?
Если очень грубо, По FK.
Например, у вас есть post и comment. Соотвественно, у поста есть комментарии.
Каждый комментарий ссылается на какой-то пост.
Если вы удаляете пост, то есть множество комментариев, которые перестают ссылаться на какой либо пост, потому что его удалили. Такие комментарии становятся сиротами (orphan) и тоже будут удалены в случае orphanRemoval true.
Вадим
Вадим
ну вот у меня на этом месте возникает ошибка FK
Viktor
ну вот у меня на этом месте возникает ошибка FK
Может, на пост еще кто-то ссылается, кроме комментариев (из моего примера)
Viktor
Кто-то, у кого orphanRemoval не проставлен
Михаил
Может, на пост еще кто-то ссылается, кроме комментариев (из моего примера)
ещё надо бы узнать в каком порядке он удаляет сирот и родителя. Хотя если он делает это в одной транзакции то это не важно. Или важно