Как организовать дедупликацию сообщений?

Например, при использовании отложенных сообщений. Если что-то пойдёт не так в брокере, например, и он не успеет втиснуть в очередь сообщение в правильном порядке дат.

Как организовать дедупликацию сообщений?

Роман Мирр, где-то ведь эта блокировка должна случиться. Или на уровне БД, или на уровне приложения. Мне кажется, у сервера Mysql это лучше выйдет сделать, нежели мне в php использовать какие то семафоры.

Как организовать дедупликацию сообщений?

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

Как организовать дедупликацию сообщений?

Я так понимаю, это будет правильно работать только если обернуть всё в транзакцию с уровнем изоляции SERIALIZABLE? Иначе как избежать фантомного чтения во всех этих вложенных селектах при параллельном инсерте.

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

Спасибо, не вчитался, видимо, вдумчиво в стандарт)

Я видел пример реализации, где в ответ присылается список ссылок вида
/endpoint.json
/endpoint.xml
и т.д

Но это работает только если формат задаётся расширением файла. А если negotiation проходит на уровне заголовков, как тут намекнуть на поддерживаемые форматы? Просто список написать?

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

Вы имеете в виду Fail Fast, наверное. Fail First это что то из разряда Die Hard :)

Как реализовать отложенные события?

ddd329, если "отдельный процесс" - это и есть Scheduler, то вы описали мой третий вариант.
Что касается того, на каком уровне находится этот класс, я не вполне согласен.
Дело в том, что именно доменный слой решает, что какое-то событие надо отложить до поры.
Условно, это произойдёт в службе предметной области (domain service). Вот там, в этой службе я должен запланировать событие. Как мне обратиться к Scheduler, если он не на доменном уровне? Я могу принять, что реализация его лежит в инфраструктурном слое, как, например, реализация всех репозиториев, но интерфейс задачника явно представляет собой службу с открытым хостом (open host service) из контекста планирования задач, то есть в домене.

Как правильно реализовать теги в Symfony?

Flying, спасибо, возьму метод на вооружение.

Как правильно реализовать теги в Symfony?

BoShurik, спасибо за интересную библиотеку для доктрины. Действительно, JSON для ValueObect'ов хорошо смотрится в разрезе поддержки со стороны Mysql. Но всё таки выборка всех тегов достаточно затруднительна в таком случае. Каждый раз перебирать все статьи, чтобы обновить такой то кэш счётчика мне не хочется.

В принципе, свою задачу я решил примерно как говорил товарищ Flying ниже, с помощью эвентов. При этом я убрал у тега ответную сторону ассоциации и теперь это простой доменный ValueObject, как и должен быть. Поиск по тегу происходит без проблем с выборкой со стороны статьи как MEMBER OF. А сам список всех тегов с количеством статей я получаю уже обычным, не доктриновским запросом с двумя join'ами по таблице ассоциаций, только в обратную сторону. Я думаю, это меньшее из зол.

Как правильно реализовать теги в Symfony?

BoShurik, Вообще, конечно, тег - это чистой воды ValueObject с точки зрения DDD. И в идеале я хотел бы, чтобы у тега вообще не было знаний о том, к чему он принадлежит, а у репозитория статей я хотел бы просто иметь возможность:

• найти записи по тегу
  
• запросить теги с количеством записей с ними
  

В текущей реализации все задачи решаются на стороне доктрины через ассоциации, хотя "DDD-ный подход" подмочен. А если поле будет JSON, то как быть с этим?

Как правильно реализовать теги в Symfony?

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

There are no restrictions to what methods can be called inside the preRemove event, except when the remove method itself was called during a flush operation.

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

Changes to associations of the updated entity are never allowed in this event, since Doctrine cannot guarantee to correctly handle referential integrity at this point of the flush operation.