Если мы говорим про дто, то оно имхо не должно меняться

написали же, сайд эффект

Вот такого поведения с сайд эффектами не добиться без сеттера
Поэтому можно забить на объекты вообще и пользоваться массивами

ассоциативные* массивы зло вообще

ни типизиции, ни валидации, ни единственно верного способа создания

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

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

Структура и типы

Есть вопрос по multiple entity managers. Настроил в doctrine.yaml несколько коннекшенов, включая default. И все работвет как надо, заисключением *master_event*. когда я добавляю новую entity - все ложиться в БД, если я пытаюсь изменить существующую entity через ->persist(entity) ругается на

1062 Duplicate entry ************** for key 'PRIMARY'

.Хотя для default конекшена все проходит через persist (на добавление или измененеие entity). В чем может быть затырка?
Вызываю entity через *$this->getDoctrine()->getRepository(EventShipment::class,'master_event')->*.... пытаюсь запихнуть через *$this->getDoctrine()->getManager('master_event')->persist($eventShipment)*

персист вызывается только для новых сущностей

для полученных из репы просто ее меняете а потом делаете флаш

$em->clear() нигде не вызывается между получением сущности и flush()?

Нет, не вызывается. В данном случае просто обновляю дату через setCreated($DTO->getDatetime()). Предполагаю что из-за этого https://highload.today/mysql-1062-duplicate-entry-for-key-primary-pri-replikatsii/ но как в этом случае действовать пока решение не вижу

у тебя еще и реплика есть?

Да

Дело в том что у default тоже есть replica, (slave_app), и там такого не происходит

Изменение стэйта само по себе сайд эффект. То есть любой метод изменяющий стэйт через присваивание - сеттер?)

А  я нет

Ну зачем утрировать. Очевидно что сеттер - это метод, основное и часто единственное назначение которого - устанавливать значение внутренней переменной. При этом сеттер конечно дает больше возможностей для управления этой переменной и это потенциально точка небольшого роста бизнес-логики (сегодня - просто ставим значение, а завтра проверяем что оно неотрицательно и т.д.) без изменения интерфейса.

И в этом смысле сеттер конечно лучше чем паблик-свойство