Проблемы возникла из-за того, что один коллега в проекте в репозиториях сохраняет flush (entity ), можно сказать это новый проект . У нас мало опыта работы с доктриной, а другие разрабы увидели и говорят, что так делать не надо.

вроде даже в гитхабе есть issue, где говорят о выпиливании, можно туда людей потыкать

вроде даже в гитхабе есть issue, где говорят о выпиливании, можно туда людей потыкать

Выше @fes0r уже упоминал о выпиливании этого из 3 версии

тут не про количество баз данных

понял, пойду перечитаю про саги.

Проблемы возникла из-за того, что один коллега в проекте в репозиториях сохраняет flush (entity ), можно сказать это новый проект . У нас мало опыта работы с доктриной, а другие разрабы увидели и говорят, что так делать не надо.

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

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

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

через сервис Flusher

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

В репозитрии

Проблемы возникла из-за того, что один коллега в проекте в репозиториях сохраняет flush (entity ), можно сказать это новый проект . У нас мало опыта работы с доктриной, а другие разрабы увидели и говорят, что так делать не надо.

ну то есть я бы просто попросил его так НЕ делать. Объяснил бы про unit of work, про все эти штуки в доктрине которые позволяют делать flush один раз как точку сохранения данных. Обсудил бы вопросы уменьшения длины транзакций, стратегии по работе с локами и т.д.

@fesor а у тебя блог есть со всеми этим выкладками?

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

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

@fesor а у тебя блог есть со всеми этим выкладками?

нет, все время на чаты уходит и на говнокодинг на проектах

я бы и сам почитал вместо чата

эх печаль )

я думал об этом, вопросы ж стандартные

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

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

это классика dry - либо раз в 3 месяца лекция про flush, либо один раз в блоге + мелкие правки )

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

для начала бы собрать цитатник по типу оопшного

до сих пор обидно что из статей на хабре больше всего плюсиков у меня за высер написанный за полтора часа, а остальные статьи которые минимум 2-3 дня занимали - меньше

ну то есть я бы просто попросил его так НЕ делать. Объяснил бы про unit of work, про все эти штуки в доктрине которые позволяют делать flush один раз как точку сохранения данных. Обсудил бы вопросы уменьшения длины транзакций, стратегии по работе с локами и т.д.

если изменены 2 агрегата, а сохранить нужно 1, как быть? ответ не делать так не убедителен, в том плане, что персистентность не должна быть никак связана с бизнес-логикой, зачем и почему я меняю два агрегата, а сохраняю только 1 - это вопрос бизнеса

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

а где его делать, в парадигме DDD ?

если изменены 2 агрегата, а сохранить нужно 1, как быть? ответ не делать так не убедителен, в том плане, что персистентность не должна быть никак связана с бизнес-логикой, зачем и почему я меняю два агрегата, а сохраняю только 1 - это вопрос бизнеса

а зачем менять два агрегата а сохранять один? изменения во втором не нужны?

если изменены 2 агрегата, а сохранить нужно 1, как быть? ответ не делать так не убедителен, в том плане, что персистентность не должна быть никак связана с бизнес-логикой, зачем и почему я меняю два агрегата, а сохраняю только 1 - это вопрос бизнеса

бизнес тоже спросит у тебя "какого хуя" обычно в такой ситуации

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

и попыткой прикрыться бизнесом

а зачем менять два агрегата а сохранять один? изменения во втором не нужны?

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

поянтно что UoW и т.п., но я вообще могу кастомно дата мепер реализовать и сохранять по 1 агрегату за раз, - в итоге получается что это доктрина мне навязывает сохранять все состояние сразу

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

проблема ли это доктрины или того что для этого был неверно выбран ORM а не Х?

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

если логика откатывает изменения - то как бы нет ничего страшного в том что бы сохранить оба агрегата

а вообще звучит как те самые компенсационные транзакции

а вообще звучит как те самые компенсационные транзакции

да, но смысл в них, если откат происходит в рамках 1 бизнес-транзакции и может быть реализован на уровне логики, до сохранения

да, но смысл в них, если откат происходит в рамках 1 бизнес-транзакции и может быть реализован на уровне логики, до сохранения

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

но опять же - не рекомендую бездумно в это лазить

Я бы и осознанно не рекомендовал))

просто инфраструктуру надо для этого годную) которой пока нет)

если ты не дотнетчик)

И вряд ли случится, имхо

Либо левые поделки, либо нихера. Это не нужно ларавель формошлёперам

Либо левые поделки, либо нихера. Это не нужно ларавель формошлёперам

но что же нам тогда делать?! Мы тоже хотим быть модными! :D (А хотя я знаю - мы будем делать микросервисы, а кто победнее - просто сервисы)

Я живое воплощение тщетности пути mba в пхп) дорого и безумно сложно. Год работы, а с того же дотнета ещё и трети не скопипижжено

Я живое воплощение тщетности пути mba в пхп) дорого и безумно сложно. Год работы, а с того же дотнета ещё и трети не скопипижжено

Master of Business Administration ?

но что же нам тогда делать?! Мы тоже хотим быть модными! :D (А хотя я знаю - мы будем делать микросервисы, а кто победнее - просто сервисы)

а кто ещё беднее - просто синхронный комманд бас

Master of Business Administration ?

Message-based arch

lol

а кто ещё беднее - просто синхронный комманд бас

а можно просто в контроллере $em->find(id), return view

?

класс

а кто ещё беднее - просто синхронный комманд бас

Эт аще дно, как по мне)

а можно просто в контроллере $em->find(id), return view

а это уже как-то совсем не модно выглядит, даже баззворда никакого нету =\

Message-based arch

ну на самом деле я думаю тут больше вопрос приоритизации фич...

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

да и вообще просто люди которые могут это сделать - им обычно впадлу)

Мне пока не впадлу) едем дальше)

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

правда тогда есть шанс стать евангелистом MBA

Да я уже)

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

хз модно сейчас это или нет но год-полтора назад было модным

В пхп не модно, и это главное горе)

Нету фидбэков и годных набросов

а можно просто в контроллере $em->find(id), return view

можно, только осторожно

В пхп не модно, и это главное горе)

99% в пхп это сайты с простым CRUD, нет потребности, - потому и не модно

99% в пхп это сайты с простым CRUD, нет потребности, - потому и не модно

Ой да ладно)

99% в пхп это сайты с простым CRUD, нет потребности, - потому и не модно

давай не рассматривать сайты)

эти самые 99% процентов проектов обычно не очень сытные

и нас больше интересует тот 1% который довольно вкусный

давай не рассматривать сайты)

а зачем тогда пхп? )

правда... я не думаю что имеет смысл это делать на php)

правда... я не думаю что имеет смысл это делать на php)

вот вот

Эт аще дно, как по мне)

у меня просто нет гошников, чтобы писали за меня

Хз) я до предела пхп ещё не дошёл, не знаю.

Дойду, перепишу на го)

Хз) я до предела пхп ещё не дошёл, не знаю.

я видимо тоже... потому php это все еще 50% моего кода. Еще 40% это тайпскрипт и еще 10% это всякие баши питоны

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

го на котлин я создал

го или котлин)

и да, там есть дсл, я узнавал

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

Хз. я фронтом не обмазываюсь, а с точки зрения бэка пока запас есть

Хз. я фронтом не обмазываюсь, а с точки зрения бэка пока запас есть

ну за UI платят больше сегодня)

потому что адекватных там еще меньше

ну за UI платят больше сегодня)

Не стоит на юай(

Как сегодня тут тихо, неожиданно)) Всем привет. Кто-то может подсказать: "leftJoin( 'AppBundle:RelSubscriptionLevel', 'rsl', 'WITH', 's.id = rsl.subscriptionId and rsl.levelId in(:level)' )" Таким образом все работает, но нужно точное совпадение по массиву, in не подходит потому, а eq - ругается

Как сегодня тут тихо, неожиданно)) Всем привет. Кто-то может подсказать: "leftJoin( 'AppBundle:RelSubscriptionLevel', 'rsl', 'WITH', 's.id = rsl.subscriptionId and rsl.levelId in(:level)' )" Таким образом все работает, но нужно точное совпадение по массиву, in не подходит потому, а eq - ругается

что значит "точное совпадение по массиву"?

Искать совпадение всех элементов массива, а не хотя бы одного)

В цикле добавить много where levelId =?

Не хотелось бы, это уже крайний вариант так сказать, не особо верится что доктрина сделала in и не сделала что то по типу eq

как правильно организовать статистику по входам юзеров ? есть юзерсы, есть "девайсы" (сущности-девайсы, install_id, type (android/ios)), как правильно замутить хранение (и отображение в админке) всей статистики по входам юзерсов через девайсы? many-to-many, очевидно напрямую мапить смысла нет через доктрину

Могу ошибаться, но тут может таки и не нужно привязки к сущностям. Только представить, объект юзера будет грузить в себя слишком много логовых..

может отдельный LogEntry (user, device, timestamp) завести?

а тут вот можно подумать про influxdb и делать связи уже по факту (после выборки)