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

вот тут поподробнее...

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

да и транзакцию нужно закрывать как можно раньше

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

как-то нет. У меня большая часть подобного запускается уже после flush по доменным ивентам (как правило)

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

ну вот давай приведу пример: есть регистрация аккаунта пользователя. Штука простая. После успешной регистрации мне надо слинковать пользователя и его страну, забить для пары рефералки связи, сгенерить еще пару штук разных...

ты про такие кейсы?

При учете того, что пользователь без линкованной страны - вообще не валидное состояние

При учете того, что пользователь без линкованной страны - вообще не валидное состояние

ну у меня "страна" вымышленная, это типа как элемент геймификации и часть другого контекста. Так что "не слинковано" это не невалидно. Просто другой контекст ничего знать не знает о пользователе и ему недоступна часть функционала.

у меня это идет в таком порядке: - регистрация пользователя - flush - эмитится событие UserRegistered с айдишкой сущности например - событие может быть обработано хоть в рамках текущего запроса хоть через очередь. А потому дальше просто разные штуки выполняются так как им надо

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

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

в контексте конкретно моей системы - это норм

если "не удалось слинковать" по каким-то причинам - мне важнее что бы регистрация прошла

не, когда это норм, тут ваще пофиг где flush :) речь именно о свзязанных изменениях... ну банально $user1->decrease(); $user2->increase()

не, когда это норм, тут ваще пофиг где flush :) речь именно о свзязанных изменениях... ну банально $user1->decrease(); $user2->increase()

в этом случае у меня сначала делается flush при добавлении новой транзакции, и генерится доменное событие, которое вызывает 2 sql запроса в своей транзакции

если тебя беспокоит атомарность (что бы небыло double spent) то тут вопрос локов

ну так эту новую транзакцию ты где стартуешь

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

p.s. у меня финансовые штуки вообще на блокчейне где то что транзакция прошла еще ничего не значит(

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

мне тоже(

ну так эту новую транзакцию ты где стартуешь

при обработке доменного события

эти "балансы" которые increase/decrease я бы менял через корень агрегата (транзакция). Но это только для write модели. Я ж не дурак лэджер делать на доктрине

а ловит это событие кто-то в persistance?

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

а ловит это событие кто-то в persistance?

эм... нет

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

обычно это когда в разных контекстах и их нужно слинковать

типа саги всякие

у меня слишком примитивные проекты, не дорос я до саг

эм... нет

т.е. код обработки события в домене?

т.е. код обработки события в домене?

когда как, иногда в домене, иногда нет

точнее именно листенеры не должны быть в домене

это как "точки входа" инициирующие новые транзакции

есть штуки типа "послать нотификашку" а есть штуки типа "слинковать два аргегата"... правда для последнего не могу придумать нормальный кейс

разве что статистика

ну вот у меня для рефералки например надо

короч я свое мнение высказал. Не ленись. это секунду занимает добавить аргумент в конструктор и ты таким образом не заметаешь проблемы связанности под ковер

Я наоборот сторонник твоего варианта. :)

короч я сча использую кастыльный эдакий недо-cqrs

без event sourcing

ну смотри, в данном случае в роли логической транзакции ты используешь событие. Т.е. все связанные иземенения, которые должны меняться в базе атомарно для других наблюдателей ты оформляешь в виде единого события... а листенер по сути uow и будет (по сути точно, а не по интерфейсу фаулеровскому)

ну смотри, в данном случае в роли логической транзакции ты используешь событие. Т.е. все связанные иземенения, которые должны меняться в базе атомарно для других наблюдателей ты оформляешь в виде единого события... а листенер по сути uow и будет (по сути точно, а не по интерфейсу фаулеровскому)

сложна... ты под uow именно границу транзакции определяешь?

uow ну типа да, атомарное изменение, для этого uow и придумали, что бы атомарно менять набор разных объектов

ну тогда типа того.... но у меня еще небыло (а может и было и я проиграю когда-нибудь) что бы эти штуки надо было с соблюдением всех зависимостей строить (типа откатилась 3-я транзакция - надо откатывать 2 предыдущие)

так и не должно быть такого

мне казалось что saga именно про это)

мне казалось, что про то, что если у нас откатилась внутрях где-то 3-я транзакция, то 2-я этого заметить не должна ;)

Надо освежить

Сергей видимо про 3й шаг одной транзакции?

Ребята, а в задеплоином приложении можно удалить /app ? конфиги скомпилированы, шаблоны тоже...

с учетом того, что перекомпиляции на проде не будет

Ребята, а в задеплоином приложении можно удалить /app ? конфиги скомпилированы, шаблоны тоже...

не

не

да у меня в итоге затык произошел когда я Resource/views удалил, остальное впринципе не сломало ничего

да у меня в итоге затык произошел когда я Resource/views удалил, остальное впринципе не сломало ничего

твиг пытается подгружать?

у меня в app ещё autoload.php и AppKernel.php лежат

Але оп

Репозиторий должен быть завязан только на доктрине?

Хры что ли

твиг пытается подгружать?

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

у меня в app ещё autoload.php и AppKernel.php лежат

ну эти понятное дело оставил =)

А если у меня отдельный сервис для проекта? Репозиторий может стучать на ендпоинт другого сервиса и десериализовывать полученные данные в модели? *(Так то норм кейс)*

Или это не репозиторий?

А если у меня отдельный сервис для проекта? Репозиторий может стучать на ендпоинт другого сервиса и десериализовывать полученные данные в модели? *(Так то норм кейс)*

сериализатор не связан с доктриной если что. Доктрину из симфони можно выпилить и писать все самому

Ты не понял

ага :(

Репозиторий должен быть завязан только на доктрине?

не должен, делай как хочешь

Сергей видимо про 3й шаг одной транзакции?

не, я про случаи когда у тебя операция разделена на три логических транзакции (микросервисы как пример)

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

то есть "откат" изменений происходит посредствам новых ивентов которые компенсируют "фэйлы"

Подскажите пожалуйста, что за фигна такая, которая возникает только при деплое на сервер. https://pastebin.com/rgnegZwj Почему доктриновские прокси недоступны? Причем это только время от времени происходит.

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

слава богу у нас пока таких кейсов нет )

Подскажите пожалуйста, что за фигна такая, которая возникает только при деплое на сервер. https://pastebin.com/rgnegZwj Почему доктриновские прокси недоступны? Причем это только время от времени происходит.

у тебя вероятно обрабатывались запросы, а var/cache при деплое снес

у тебя вероятно обрабатывались запросы, а var/cache при деплое снес

Так я думал сносить кэш - должно быть безобидным занятием?

то я б писал на зенде)

По какой причине если не секрет?

Так я думал сносить кэш - должно быть безобидным занятием?

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

По какой причине если не секрет?

ну на тот момент лет 6 занимался именно зендой и на ней писал лучше всего) сейчас бы выбрал kotlin+spring

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

Так деплоер делает все это ж.

Так деплоер делает все это ж.

может, параллельно с очисткой кэша деплоер ещё что-то делает

нее

тут request, значит, вероятно http запросы

может, параллельно с очисткой кэша деплоер ещё что-то делает

Я потом вручную почистил кэш. Проблема осталась.

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

нет, транзакции начинаются когда у тебя для одной операции нужно более одной операции записи

привет, подскажите плиз, возможно ли из кода поменять параметры стороннего бандла?

wow

кто-нибудь знает какой симфоневский адаптер сохранит кэш в файлик var/cache, а не в /tmp (tmpfs)

Всем привет. Как можно в бандле зарегистрировать несколько расширений контейнера public function getContainerExtension() { return [ new UserExtension(), new PostExtension() ]; } Хотелось что-то типо такого

Можно ли

Ребята, вопрос по рейс кондишенам и архитектуре согласованности в очередях

У вас тоже телеграм не работает?

С телефона вроде ок, с компа вообще не фурычит (убунта)