Апдейты при локах в БД приведут к pdo exception в приложении и к закрытию EntityManager.

Можно использовать filesystem read lock в качестве альтернативы

Всем привет, вопрос по доктрине: является ли инъекция EntityManager в сервисы плохой практикой? Он ведь по сути является глобальной точкой доступа ко всем сущностям в проекте. И где вы flush'ите изменения, в контроллере?

я стараюсь оставлять entity manager nолько в своих репозиториях. И да, flush в контроллере потому что это единственное место где можно определить границу бизнес транзакции

На данный момент, флашу тоже в репозитории, в методе типа save

это очень плохая идея

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

тогда как бы ок но в этом нет смысла

я стараюсь оставлять entity manager nолько в своих репозиториях. И да, flush в контроллере потому что это единственное место где можно определить границу бизнес транзакции

Тогда надо делать метод add/update в репозитории и флашить в контроллере, как ты написал)

Хорошая идея

Тогда надо делать метод add/update в репозитории и флашить в контроллере, как ты написал)

update не нужен

update не нужен

+

Почему?

у тебя если сущность ты достал и она уже крутится в unit of work (managed entity) то она уже там

это если ты не менял настройки конечно

А если вы решите на натив перейти?

А если вы решите на натив перейти?

напишу свой unit of work

Я знаю, что сущность уже в менеджере

Почему?

https://www.slideshare.net/mobile/Yaboomaster1/save-repository-from-save

да и потом

Спасибо, почитаю)

напишу свой unit of work

Действительно?)

да, это не сложно

напишу свой unit of work

Возьми готовый)

Эти 100 строк будеи просто впадлу писать

Возьми готовый)

я пробовал - не нашел. Это как менять доктрину на любую другую ORM с UoW

Короче в репозиторий только метод add добавлять и все

да

у меня другой вопрос - у тебя реально были прицеденты когда ты отказывался от Doctrine?)=

И remove/find

Ну просто может быть такая ситуация, где некоторые репозитории прийдется реализовать нативно, без доктрины. Для перфоманса

Не было)

remove только если надо, я сейчас придерживаюсь того что бы remove почти никогда небыло

Я понимаю что это маловероятно, но для долгих проектов вероятно

тут если у тебя проект будет чувствителен к лэтенси

и именно на запись

Ну да, согласен

это настолько маловероятно, что прям ух

remove только если надо, я сейчас придерживаюсь того что бы remove почти никогда небыло

Ну если агрегат представляет не конечный процесс, а конец идет из вне, да

Ну если агрегат представляет не конечный процесс, а конец идет из вне, да

тут болььше вопрос в том что ты собрался удалять

тут болььше вопрос в том что ты собрался удалять

Агрегат очевидно)

не, я мол с точки зрения бизнеса, знаешь ли ты что тебе можно это дело удалять?

из моего опыта крайне редко надо именно удалять

+

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

Ребята, хотел спросить, вы cascade=persist юзаете?

да, юзаем

причем активно

не, я мол с точки зрения бизнеса, знаешь ли ты что тебе можно это дело удалять?

Ну да, если жизненный цикл сущности не предпологает переход в конечное состояние, которое равносильно удалению

я хочу попробовать prooph

вот к слову вопрос на тему аргегатов и event sourcing

допустим у тебя есть сущность и тебе нужны комменты например

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

пересчет рэйтингов

Глупый вопрос, но вы действительно Сергей Протько?)))

Глупый вопрос, но вы действительно Сергей Протько?)))

возможно

@mkusher короч хз как с es это делать... количество объектов может быть приличным. Или лучше не делать подобного таким образом?

@mkusher короч хз как с es это делать... количество объектов может быть приличным. Или лучше не делать подобного таким образом?

это похоже на какой-то банальный круд, хз будет ли профит

я хочу попробовать prooph

Это что?)

Это что?)

http://getprooph.org/

@fes0r @mkusher мне интересно вот ваше мнение: Проект на Ларавел, юзаю доктрину. Разделил на модули. Допустим, модуль User. Создал класс UserManager, который отвечает за создание, просмотр и редактирование пользователей. В него я инжектю репозиторий и через него достаю юзеров, создаю и так далее. Но мне кажется, что я не правильно делаю, так как после разговора выше, понял, что надо флашить уже в контроллере, а я это делаю в репозитории. Как вариант, инжектить и UserManager, и EntityManager в контроллер, и после того, как UserManager сделает все свои дела по созданию юзера и добавит его в репозиторий через add(), вызвать флаш. Был бы благодарен за ваши комментарии.

а зачем вам UserManager?

Для создания объекта, редактирования и read-функций

ERROR: S client not available

Под созданием и редактированием подразумеваю не только добавить в репо, но и сопутствующие поверки/валидация, связанные с бизнес-логикой

Может название не лучшее, но на данный момент вот так

Под созданием и редактированием подразумеваю не только добавить в репо, но и сопутствующие поверки/валидация, связанные с бизнес-логикой

а почему это не в User?

@fes0r @mkusher мне интересно вот ваше мнение: Проект на Ларавел, юзаю доктрину. Разделил на модули. Допустим, модуль User. Создал класс UserManager, который отвечает за создание, просмотр и редактирование пользователей. В него я инжектю репозиторий и через него достаю юзеров, создаю и так далее. Но мне кажется, что я не правильно делаю, так как после разговора выше, понял, что надо флашить уже в контроллере, а я это делаю в репозитории. Как вариант, инжектить и UserManager, и EntityManager в контроллер, и после того, как UserManager сделает все свои дела по созданию юзера и добавит его в репозиторий через add(), вызвать флаш. Был бы благодарен за ваши комментарии.

похоже дело в то, что ты пытаешься использовать data mapper как active record у тебя может быть ситуация ты например создаешь пользователя и партнерский купон для этого пользователя. сохранение данных в субд будет происходить единовременно для пользователя и купона в рамках одной транзакции если flush будет в теле метода контроллера

репозитории стоит использовать для сложной логики получения или обработки данных которые находятся в СУБД

dypa да, за флаш я понял уже, его в контролёре запускать)

а почему это не в User?

Ты имеешь в виду User::create(someData)?

кто вас научил писать "за"?!

Ты имеешь в виду User::create(someData)?

User::register наверное

ну вообще да

кто вас научил писать "за"?!

Не понял вас)

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

Косяки обучения :/

ну вообще да

А в данном случае User - это как своего сервис получается? Или модель, так сказать?

А в данном случае User - это как своего сервис получается? Или модель, так сказать?

это сущность, в терминах доктрины и почти в терминах ddd

@mkusher Угу, я понял вас. То есть создание и редактирование мы инкапсулируем в сущность User, в контроллер инжектим репозиторий и созданную сущность добавляем через репо. Причина, по которой я сделал менеджера, это из-за готовых контролеров админки, хотел облегчить высокую вероятность перехода на другую админку

@mkusher можно ещё совет один, пожалуйста: валидацию данных, которые идут в сущность, например в User::register($data), лучше делать до того, как вызывается метод регистрации, то есть в контроллере или в request объекте, или в самой сущности держать правила валидации.

@mkusher можно ещё совет один, пожалуйста: валидацию данных, которые идут в сущность, например в User::register($data), лучше делать до того, как вызывается метод регистрации, то есть в контроллере или в request объекте, или в самой сущности держать правила валидации.

::register в идеале принимает уже готовые объекты

Там особо нечего валидировать

я пробовал - не нашел. Это как менять доктрину на любую другую ORM с UoW

https://github.com/isolate-org/unit-of-work/blob/master/src/Isolate/UnitOfWork/UnitOfWork.php а этот не норм?

Ребят тут такая проблема нарисовалась, когда начал приводить всю систему в тестируемый вид. Подскажите, как можно выкрутиться, глаз уже замылен. Проект имеет несколько ролей и штук пять таблиц у которых есть user_id. В зависимости от того, какой юзер вошел надо либо ограничить выборку по всем таблицам только по этому юзеру, либо ограничить по списку пользователей ему доступных. Ладно уж, ограничение выборки можно пропихнуть в Criteria, но как быть с апдейтом и удалением: как добавить условия к апдейту (and where user_id = 1) и к удалению, чтобы юзер с лоу-левел правами не смог обновить запись которая ему не принадлежит (подменив её id)? Пока вижу только одно хреновое решение - для подобных репозиториев написать трейт, который будет ограничивать выборку в зависимости от роли. Но черт побери, подкоркой понимаю, что не должна там быть проверка на права доступа. Логика разбрасывается по всему проекту. Что делать, как быть, кому молиться? :)

Вот такая штука должна быть глобальна для всего проекта. https://gist.github.com/roquie/4b78e4bf11488bb09ec01701bb11bd51 Или это дичайший говнокод и надо как-то иначе решить эту проблему?

в doctrine сделано так http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/filters.html

Я уже и так думаю выкинуть eloquent и переписать с доктриной это добро, останавливает только объем кода

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

глобал скоуп лары не подойдет, потому что при ограничении выборки как у меня выше, будет зацикливание (было по крайней мере) для User модели, поэтому поверх Eloquent нахерачили слой репозиториев, со своим скоупингом.

Я уже и так думаю выкинуть eloquent и переписать с доктриной это добро, останавливает только объем кода

Я так сразу и сделал, как проект начал)

в doctrine сделано так http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/filters.html

не стоит юзать фильтры

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