Ну по факту вызывается 10 раз, но в базу уйдет же последнее значение.
Ну для этого есть разного рода шаблоны типа throttling или debouncing. Но лучше дейстительно пересмотреть работы с ивентами
Ну вот допустим там есть какое то еще действие по мимо изменения поля, которое нам нужно в риде. Если более конкретно, то навернео лучше пример с не 10 вызовами 1 метода, а разные методы. Например в одном юзкесе мы меняем 3 поля (я про изменение в БД) через 3 метода. Генерятся 3 ивента (у которых есть свои подписчики, не связанные с рид). Но так же на каждый ивент повешено и изменение рид,и выходит на 1 транзакцию в БД, 3 транзакции в риде.
А почему много ивентов однообразных? Это правда проблема или просто факт подмеченный?
Это не проблема, это факт. Ивенты могут быть и не однообразаные.
Однообразных ивентов не бывает, так как это не круд
Допустим сущность в ходе юзкейса меняла свой статус 3 раза, причем возможно даже вернулся статус обратно. Каждая смена - это + один ивент. По итогу 1 коммит. Вот кстати кейс интересный. Нужно ли тут генерить 3 ивента и релизить или 1 последний и как тогда лучше это сделать и замержить их. Хотя наверное от БЛ зависит.
Как вариант, события записываются в табличку, проставляется у них дата/версия. Фильтровать и коммитить только последнее событие
Странный юзкейс, что три раза статус поменялся. Можно пример?
во время релиза можно проверить последний, релиз на то и релиз
Конкретный пример привести не могу. Это больше рассуждение на возможный кейс Видел такое: большой цикличный воркфлоу (из 2 десятков отдельных обработчиков), в котором статус помещения для аренды менялся в зависимости от других сервисов и состояний в них. Правда там не было атомарной транзкции и доменных ивентов :)
в воркфлоу есть состояния и переходы, просто машина состояний — схема/план но операции перехода выполняются в каких-то бизнес-процессах, которые единичны по своей сути
Воркфлоу запускал бизнес процессы.
Обсуждают сегодня