Как вариант это сделать асинхронно, но хочется понять нету ли точно другого пути

Как вариант это сделать асинхронно, но хочется понять нету ли точно другого пути

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

Окей > Каким образом можно стартануть новую транзакцию после флаша? Новый $uow->flush() должен заново сохранить все измененные сущности. Если я правильно понял вопрос

привет, подскажите плиз. Есть листенер который на postFlush вызывает доменные события. В доменных событиях какие-то значения сущностей обновляются и мне снова надо записать в бд. Каким образом можно стартануть новую транзакцию после флаша?

postFlush() { events = uow.releaseEvents() If(events.empty()) return dispatchEvents(events) flush() }

важный момент - не допусти рекурсию в этом месте. У меня это выход если небыло ни одного ивента.

в идеале конечно каждый твой листенер должен свой UoW иметь

но пока это проблематично сделать

postFlush() { events = uow.releaseEvents() If(events.empty()) return dispatchEvents(events) flush() }

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

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

такое бывает, у доктрины полно багов в этом плане)

потому повторюсь - в идеале у тебя должны быть отдельные UoW

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

а вообще - если у тебя все это не закрыто одной большой транзакцией сверху, то есть смысл мувнуть все листенеры в отдельный процесс (через rabbitmq/zeromq pub/sub)

а вообще - если у тебя все это не закрыто одной большой транзакцией сверху, то есть смысл мувнуть все листенеры в отдельный процесс (через rabbitmq/zeromq pub/sub)

так и сделаем) спасибо большое

всем привет. подскажите пжлст, меня или глючит и такая фича была, или я что-то выдумал. допустим у нас есть query builder или обычный findBy в репозитории и какая-то сущность, у которой объект имеет свойство $date с mapping type = "date"(не datetime). Если я делаю findBy(['date' => new DateTime()]), то мой объект DateTime должно преобразовать в строку с датой в формате Y-m-d которая потом попадёт в sql запрос?

или же findBy(['date' => (new DateTime())->format('Y-m-d')]) надо делать?

или же findBy(['date' => (new DateTime())->format('Y-m-d')]) надо делать?

первое

всем привет. подскажите пжлст, меня или глючит и такая фича была, или я что-то выдумал. допустим у нас есть query builder или обычный findBy в репозитории и какая-то сущность, у которой объект имеет свойство $date с mapping type = "date"(не datetime). Если я делаю findBy(['date' => new DateTime()]), то мой объект DateTime должно преобразовать в строку с датой в формате Y-m-d которая потом попадёт в sql запрос?

да

но ты попробуй оба варианта и посмотри разницу

я посмотрел логи. дата не преобразовывается

вместе со временем отправляется в мускуль

всем привет. подскажите пжлст, меня или глючит и такая фича была, или я что-то выдумал. допустим у нас есть query builder или обычный findBy в репозитории и какая-то сущность, у которой объект имеет свойство $date с mapping type = "date"(не datetime). Если я делаю findBy(['date' => new DateTime()]), то мой объект DateTime должно преобразовать в строку с датой в формате Y-m-d которая потом попадёт в sql запрос?

вся магия (конвертация) происходит в doctrine type, посмотри исходники типа date

вся магия (конвертация) происходит в doctrine type, посмотри исходники типа date

всё таки в логах писало не те данные. указывались входящие, а не реальные для отправки в бд. DateType норм конвертит дату, спс

чот приехал на другой проект и там Карбон повсеместно ипользуют и я вот чо не очень прочувствовал этот момент да не много синтаксического сахара но тащить зависимость Или кто знает киллер фичу карбона?

чот приехал на другой проект и там Карбон повсеместно ипользуют и я вот чо не очень прочувствовал этот момент да не много синтаксического сахара но тащить зависимость Или кто знает киллер фичу карбона?

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

юзал карбон, переехал на chronos

то же самое, но иммутабельное

киллер фича - сравнение, да

/link@yetanotherstatsbot

https://b.yasb.exileed.com/telegram/chat/1001091570538

https://dev.to/scottshipp/avoid-getters-and-setters-whenever-possible-c8m

может кто знает, почему singleScalarResult в тестах может возвращать старое значение?

не актуальное в бд

https://dev.to/scottshipp/avoid-getters-and-setters-whenever-possible-c8m

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

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

А как же языки с нестрогой типизацией? В PHP типа входящего параметра можно ограничить только сеттером: public function setDate(DateTime $date) : void { $this->date = $date; }

А как же языки с нестрогой типизацией? В PHP типа входящего параметра можно ограничить только сеттером: public function setDate(DateTime $date) : void { $this->date = $date; }

это не проблема

это не проблема

Выкладывай

я про "ограничить"

почему только сеттером? а в конструкторе?)

мне ничего не помешает, по хорошему вместо DateTime туда засунуть что я захочу

мне ничего не помешает, по хорошему вместо DateTime туда засунуть что я захочу

Дело не во вредителях, а отлове ошибок

тайп хинты же везде куда можно засунуть ))

кроме паблик свойств

почему только сеттером? а в конструкторе?)

А если я не задаю параметры через конструктор? Положим у меня сущость и 100 аттрибутов в ней, не буду же я 100 аргументов в конструктор пихать, надо помнить очередность, какие-то аргументы надо пропускать и т.д.

можно бить на value object и группировать их

а почему 100 а не 1000 ?)

А если я не задаю параметры через конструктор? Положим у меня сущость и 100 аттрибутов в ней, не буду же я 100 аргументов в конструктор пихать, надо помнить очередность, какие-то аргументы надо пропускать и т.д.

почему нет?

а с сеттерами ты не забудешь их все заполнить?) их же 100 штук это 100 методов вызвать

Решил ты значит такой сделать: $article = new Article; // Тут ты еще не знаешь, как статья называется, или еще чего-то не знаешь // Делаешь кое-какие вычисления и... $article->setDate('2007-01-01') Тут PHP не даст тебе так сделать

а с сеттерами ты не забудешь их все заполнить?) их же 100 штук это 100 методов вызвать

ой да пусть пишет

какая разница

а с сеттерами ты не забудешь их все заполнить?) их же 100 штук это 100 методов вызвать

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

Пятничный срачик. Наканецта

это самая большая боль в разработке обычно на проектах?)

порядок аргументов?)

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

если не всегда надо задавать все атрибуты сущности - возможно тебе стоит разделить сущность)

Жги

это самая большая боль в разработке обычно на проектах?)

обычно тупые аналитики и "ребят нам завтра в прод это надо"

Жги

let the pukans burn

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

Логичные имена. Давай об этом поговорим?

ERROR: S client not available

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

а сеттеры на этом фоне - это легкое покалывание...

90% если есть сеттеры то нет тестов) (хотя тут я манипулирую - просто 90% что тестов нет)))

ахахах

юнит тестов точно не будет (честных изолированных) - и тут уже как раз таки потому что сеттеры и геттеры (хотя тоже скорее всего есть 10% из категории другое)

хорошо если будут интеграционные или e2e

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

неплохая статья....

@fes0r, я готов вернутся к давнему вопросу. Как с имутабельной сущностью не юзая persist заапдейтить сущность?

@fes0r, я готов вернутся к давнему вопросу. Как с имутабельной сущностью не юзая persist заапдейтить сущность?

давай по другому.... вот у тебя есть имутабельная сущность, так? и ты делаешь другую - новую сущность. С уже новым стэйтом. Ведь так имутабельность работает. Эти сущности имеют одинаковый идентификатор, то есть в один момент времени мы имеем 1 сущность с двумя разными стэйтами. И это уже не порядок, не находишь?

если ты хочешь заменять стэйт - юзай VO

там такая ситуация вполне корректна

дальше идет смешание понятий "сущность доктрины" и "сущность" как элемент декомпозиции систем.

давай по другому.... вот у тебя есть имутабельная сущность, так? и ты делаешь другую - новую сущность. С уже новым стэйтом. Ведь так имутабельность работает. Эти сущности имеют одинаковый идентификатор, то есть в один момент времени мы имеем 1 сущность с двумя разными стэйтами. И это уже не порядок, не находишь?

Ну давай с новой даже версией.

ограничения твоей ORM которые просто не позволят делать красивую и чистую модель (ибо наследуют ограничения реляционной модели - одно только ограничение на отсутствие односторонней one-to-many ассоциации чего только стоит)

Ну давай с новой даже версией.

с новой версией вопросы те же

что тебе мешает сделать сущность с двумя полями - id и state?

Лады. С версией я неудачно, наверн

и спокойно подменять стэйт

потом может быть еще рядом появятся поля "когда поменялся стэйт"

или, быть может - история изменения стэйта

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

Через 10 мин смогу нормально засесть. Попишу)

Через 10 мин смогу нормально засесть. Попишу)

окей, я неподалеку чуть что

Логичные имена. Давай об этом поговорим?

Что понятнее? 1) $user = new User( 'alfred', 'hitchcock', '13-08-1899', '29-04-1980', '178', false, true, false, User::TYPE_AUTHOR, Land::USA ) 2) $user = new User; $user->setFirstname('Alfred') ->setLastname('Hitchcock') ->setBirthdate('13-08-1899') ->setDieddate('29-04-1980') ->setHeight('178') ->setIsModerated(true) ->setIsAlive(false) ->setType(User::TYPE_AUTHOR) ->setLand(Land::USA) ;

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

Что понятнее? 1) $user = new User( 'alfred', 'hitchcock', '13-08-1899', '29-04-1980', '178', false, true, false, User::TYPE_AUTHOR, Land::USA ) 2) $user = new User; $user->setFirstname('Alfred') ->setLastname('Hitchcock') ->setBirthdate('13-08-1899') ->setDieddate('29-04-1980') ->setHeight('178') ->setIsModerated(true) ->setIsAlive(false) ->setType(User::TYPE_AUTHOR) ->setLand(Land::USA) ;

Билдер

Билдер

Плюс неймы

И плюс ide светит

Плюс можно вызвать в любой части кода

Плюс можно пропускать что хочешь