Павел
Контракт флашера
Юра
Флаш это точка синхронизации кода и бд
Юра
Она не должна быть размазана везде
Юра
Приложение в памяти кажется бредовым
Павел
Ну короче имхо холивар, я сам юзаю флаш отдельный. Но не могу однозначно сказать, что мне это однозначно нравится
Павел
Приложение в памяти кажется бредовым
Почему? Почему приложение зависит от инфры? Какая разница: память, мускул, эластика
Юра
Тогда тебе понравится наверное явно стартовать транзакции
Юра
Потому что юзер сохранился а дальше ошибка и отлуп
Юра
На половину процесс сделался
Юра
Это типичный лапшеподход
Павел
Тогда тебе понравится наверное явно стартовать транзакции
А в чем проблема, если мы подразумеваем сохранение 2 сущностей?
Юра
Сохранится одна и все
Юра
Вместо двух
Павел
Типа флаш в котором внутри траназакция - не лапаша, а транзакция сама по себе лапша?
Юра
Вторая например не сохранилась из-за дупликейт ки или что-то еще
Павел
Вторая например не сохранилась из-за дупликейт ки или что-то еще
Ну так, транзакцией должно быть обернуто, если должно быть атомарно
Юра
Как ты будешь откатывать неуспешные операции?
Павел
Вторая например не сохранилась из-за дупликейт ки или что-то еще
По хорошему 1 агрегат - 1 транзакция)
Павел
Как ты будешь откатывать неуспешные операции?
Оборачивается в транзакцию, как делает флаш. Ручная транзакция западло?
Павел
Единый uow - вот беда, да
Юра
Не ну если тебе нравится делать двойную работу делай
Юра
Сначала разбить на две транзакции а потом обернуть в одну транзакцию
Павел
Не ну если тебе нравится делать двойную работу делай
Пфф, кто то вообще даже флаш не юзает, оборачивает в мидлваре баса или как то так.
Т.е. ты делаешь двойную работу) вызывая флаш руками )
Павел
Все относительно
Павел
Это все инфраструктурный слой
Павел
Короче о чем мы беседуем я хз.
Я сам юзаю флаш вне репо, так как это удобнее в некоторых местах.
Но архитектурно мне не нравится
Павел
Симфа вон тоже начала пихать в репо, хоть и криво
Юра
В басе логично, ты обработал сообщения и онг сделало фдаш, ОДИН атомарный
Павел
В басе логично, ты обработал сообщения и онг сделало фдаш, ОДИН атомарный
Кто это мешает сделать если save в репо?
Юра
А если у тебя флаш кругом во всех репах то будет непонятно
Павел
А если у тебя флаш кругом во всех репах то будет непонятно
Хз, вроде все понятно. Если save - то ушло в БД, если снаружа транзакция - то в транзакции
Юра
Кто это мешает сделать если save в репо?
Мешает то что в другом репо будет флаш, и теперь ты вынужден все это оборачивать в транзакцию
Павел
Так то флаш тоже не скидывает в БД, если снаружи транзакция
Павел
Мешает то что в другом репо будет флаш, и теперь ты вынужден все это оборачивать в транзакцию
В чем проблема, кроме того что тебе лень сделать 2 строчки кода еще?
Юра
Я не понимаю зачем? Зачем мне флашить в репе?
Юра
Что это дает?
Юра
Это сайд эффект
Павел
В приложении нет контракта FlushInterface
Павел
Давай лучше по контрактам рассуждать
Юра
Флаш это сайд эффект
Юра
Нарушение single responsibility
Павел
В случае флаша внутри :
UserRepositoty::save
В случае снаружи
UserRepositiry:add
FlusherInterface
Павел
Юра
Юра
Вьпервом случае у тебя TransactionInterface еще не забудь
Павел
Вьпервом случае у тебя TransactionInterface еще не забудь
Ок, у меня он есть и во втором случае
Павел
Вьпервом случае у тебя TransactionInterface еще не забудь
Давай поговорим про это:
UserRepositiry:add
FlusherInterface
Это верно?
Юра
Да. Транзакция это тот же флашер под капотом
Юра
Заменил одно на другое и что ?
Юра
В чем Профит?
Павел
Да. Транзакция это тот же флашер под капотом
Теперь опиши плиз, если 2 сущности в разных БД - одна в эластике (твой личный репо), другая в доктрине, какие будут интерфейсы?
Юра
Будет сервис который это все будет делать внутни себя
Павел
Будет сервис который это все будет делать внутни себя
Какие интерфейсы будут у репозиториев 2-ух сущностей и как будет рабоатть флашер для сброса в эластику?
Павел
Какая нам разница в мускуле или в эластике?
Павел
Приложение не должно зависеть от персистенса
Юра
Без понятия. Ты предложил какой-то экзотический сетап и споашиваешь
Юра
Я тебе говорил про обычную работу с базой
Павел
Приложение не должно зависеть от персистенса
Павел
ИНверсия зависимостей
Юра
Откуда я знаю твою логику. Приложение не зависит от персиста. А кто зависит?
Павел
Откуда я знаю твою логику. Приложение не зависит от персиста. А кто зависит?
Да какая тут логика. Юзер в базе, заказ в эластике. Сохранянием оба в одном кейсе
Павел
Я говорю не за атомарность, а за контракты
Юра
Все зависит так не бывает. Напрямую или через другую зависимость. Если такое приложение зависит от сервиса который зависиь от персиста значит твое приложение зависть и от персиста
Dmitry
Да какая тут логика. Юзер в базе, заказ в эластике. Сохранянием оба в одном кейсе
Doctrine\ORM\EM->flush()
Doctrine\ODM\EM->flush()
Павел
Doctrine\ORM\EM->flush()
Doctrine\ODM\EM->flush()
Не через доктрину работаем. Писать свой uow?
Павел
Я написал свой кастомный репо в этой задаче. Не на доктрине мир живет весь
Dmitry
Я говорю не за атомарность, а за контракты
А для надёжности операции в разных модулях через сагу
Юра
Ага либо бесконечные фикс и синк скрипты на коленках
Павел
А для надёжности операции в разных модулях через сагу
Это понятно, мы развиваем тему контрактов :)
Павел
Если бы были бы разные флашеры для каждой сущности - это лучше ложится
Павел
Единый флашер архитектурно - хренова
Павел
Но удобно
Dmitry
Я написал свой кастомный репо в этой задаче. Не на доктрине мир живет весь
Если это Collection-Like репа, то с UoW без save(entity)
Если это Storage-Like, то без UoW и с save(entity)
Павел
Если это Collection-Like репа, то с UoW без save(entity)
Если это Storage-Like, то без UoW и с save(entity)
Ну я выше писал, что не на UoW мир завязан и об этом писал