Важен размер твоих бизнес-транзакций

Если все просто, то можно отойти и прямо вот в репозитории сейвать

Можно вообще в модель dao передавать

в джаве в принципе много раз видел что метод помечают как Transactional и внутри делают сейвы по разным репосам если их нужно несколько

ну либо юзают напрямую сессию, но только для транзакции

Ну, консистентность сложнее поддерживать кмк

Но я ещё ко всему и слабо понимаю смысл

А save может ещё и сущности дергают?))

не чисто persist($entity) & flush($entity)

Так зачем?

вот даже у core разрабов симфони спрашиваю >I don’t see anything wrong in having these methods on a repository, but i prefer to use domain-specific names >Users::register(User $user)

Add/remove норм

Здесь add

А где update?

update такого понятия нет если это managed entity

там только flush нужен

Ну

Так зачем что-то делать, если можно не делать?)

чтобы не тащить зависимость em

чтобы не тащить зависимость em

Куда о.о

удобно ж

Не очень

ну у тебя есть UserRepository

А куда ты тащишь em

ты сделал скажем find, потом чет наколбасил и тут же сделал save

ты сделал скажем find, потом чет наколбасил и тут же сделал save

А он сделал save только user

А надо было ещё чего-то

Продукта там счётчик обновить

ну репос то юзера

нах еще что-то)

Ну потому что действие бизнес затронуло

Несколько вещей)

тогда уже нужен em и транзакция

В итоге у меня состояние невалидное

а я говорю за элеметарные атомарные апдейты

Я не хочу думать как там сущности трогали друг друга

Я хочу в контроллере флаш

Если не было эксепшенов

Если это была команда

А не query

Я хочу в контроллере флаш

если б это всегда все так просто было

Так а что не так?

Я же и прошу кейс :)

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

и только потом сохранять все остальное

Зачем??

1. Uuid 2. Doctrine сама умеет подставлять

а без uuid?

2

чтобы подставить инкремент нужно знать предыдущий счетчик

или ты о чем?

Ну, зачем тебе чей-то I'd?

Id

вот нужен был, деталей не вспомню) куда-то он отправлялся на другой сервис

Так это ивент хандлер

Типа зарегил и нового юзера

После разослали имейлв

И прочую шнягу

и?

Ну

Сделали в контроллере флаш

И стартанули ивенты или на пост флаше обработчик дернул нужные сервисы нотификации

Но там уже с сущностями ничего не происходит

Только данные считываем

Может даже не из сущностей, а из dto

Или read model

В конце концов ты можешь запустить две или n бизнес транзакции, после каждой делая флуш

Но это ооочень специфичный кейс был бы

В любом случае флаш в контроллере

В конце концов ты можешь запустить две или n бизнес транзакции, после каждой делая флуш

вот именно они и нужны

я не сторонник флаша в контроллере

Ну так явно контроллер запускает две бизнес транзакции

с роллбеками и логикой контроллер тоже занимается?

На каждую флашит(или нет)

с роллбеками и логикой контроллер тоже занимается?

Какой логикой?

ну скажем если что-то пошло не так, при роллбеке нужно еще какую-то логику выполнять

Преобразования и валидации? Он дергает да

а контроллер и логика как бы не очень совместимые понятия

ну скажем если что-то пошло не так, при роллбеке нужно еще какую-то логику выполнять

Это опять же как нотификации

Они могут быть на успех и на феил свои

Или ты хочешь другую транзакцию запускать?

Александр а ты шо тут забыл?)

Или ты хочешь другую транзакцию запускать?

разные транзакции

Александр а ты шо тут забыл?)

ну так драсте

Пришел мысли умные читать

разные транзакции

разные транзакции в одной бизнес операции параллельно?

Старших товарищей слушать

например создать юзера, и добавить к его карту продукты

зачем?

например создать юзера, и добавить к его карту продукты

ты ну норм, из контроллера два каких-то сервиса дергаются, а между ними флуши

или хз, может тут один флуш вообще нужен?

там надо смотреть как че

Посоветуйте какой-нибудь бандл, который позволяет большое количество данных фикстурами загонять? В идеале, чтобы им можно было уже из существующей БД экспортировать записи для последующего использования в фикстурах.

DoctrineFixturesBundle смотрел?

http://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html

Да, конечно. Но он не об этом.

К нему можно прикрутить, конечно, импорт из JSON/XML или ещё чего угодно, что придумаешь, но вероятно же эту задачу кто-то уже решал много раз.