тогда как решается подобная задача? тру вэй каконийть есть?

тогда как решается подобная задача? тру вэй каконийть есть?

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

но скоупы, особенно "дефолтные скоупы" в AR это признанный антипаттерн.

и только для подобного

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

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

Есть запросы из таблиц, аля достать все записи. У каждой записи прописан user_id. Надо для определенных пользователей вытаскивать только их записи. Таких таблиц много, тут либо для каждого репозитория применять класс-критерий, либо делать его глобальным для всех.

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

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

Есть запросы из таблиц, аля достать все записи. У каждой записи прописан user_id. Надо для определенных пользователей вытаскивать только их записи. Таких таблиц много, тут либо для каждого репозитория применять класс-критерий, либо делать его глобальным для всех.

шаблон "спецификация" погугли

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

это не логика

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

почему?! это же документированные возможности инструмента

это не логика

а что это?

почему?! это же документированные возможности инструмента

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

доктрина имеет много очень опасных фич

часть к 3-ей версии наконец удалят

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

короч задача решается тупо на уровне репозитория для каждой из твоих сущностей

просто добавляешь условие руками, явно

делается это за 5 минут

предсказуемо

и в случае изменения требований все будет так же предсказуемо

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

их поведение вполне предсказуемо и явно)

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

короч дело твое

я выразил свое мнение

явное лучше неявного, и я не стал бы использовать для логики приложения (особенно на начальных этапах) фичи которые машнят что-то в hint-ах query

шаблон "спецификация" погугли

Не понимаю, как он поможет, если isSatisfiedBy должен вернуть тру/фолс в зависимости от удовлетворения условия. Ну удовлетворяет всем условиям, а дальше мне надо изменить сам запрос и передать его объекту дальше на растерзание. Вот изменение запроса, это уже не спецификация ведь, а как раз таки скоуп.

просто добавляешь условие руками, явно

дык тогда я так добавлю 5 условий для 5 таблиц, чет не красиво, либо куда-то выносить, аля трейт (тоже криво)

дык тогда я так добавлю 5 условий для 5 таблиц, чет не красиво, либо куда-то выносить, аля трейт (тоже криво)

преждевременное обобщение логики и преджевременная оптимизация (не только с точки зрения производительности) - не хорошо

дык тогда я так добавлю 5 условий для 5 таблиц, чет не красиво, либо куда-то выносить, аля трейт (тоже криво)

просто оставь дублирование

поверь, это уже не преждевременно :) это уже рефакторинг

не поверю)

Что то везде про это паттерн спецификация? Это какая то мода?

это очень удобно в контексте доктрины просто

Если я просто буду делать запросы в доктрине, это плохо?

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

Если я просто буду делать запросы в доктрине, это плохо?

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

короч задача решается тупо на уровне репозитория для каждой из твоих сущностей

в случае если не используются методы вида findBy* - тогда, делается кастомный queryBuilder с доп условием. но тогда есть шанс перейти границу когда ты уже не используешь преимущества doctrine и писать просто sql становится проще

в случае если не используются методы вида findBy* - тогда, делается кастомный queryBuilder с доп условием. но тогда есть шанс перейти границу когда ты уже не используешь преимущества doctrine и писать просто sql становится проще

для списочков я считаю что писать просто sql вполне себе норм вариант

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

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

Ещё вопрос. Так и не осознал. Должен ли уметь репозиторий сохранять или нет?

Или отдельный класс должен?

почитай про unit of work

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

маппинг это громадный плюс при операциях чтения вообще то

Ещё вопрос. Так и не осознал. Должен ли уметь репозиторий сохранять или нет?

не должен

маппинг это громадный плюс при операциях чтения вообще то

SELECT new MyDTO(u.id, u.name)

Ещё вопрос. Так и не осознал. Должен ли уметь репозиторий сохранять или нет?

если коротко, если ты достал сущность через доктрину и она попала в unit of work то при flush она сохранится сама по себе.

не поверю)

пока я вижу только один выход - прикрутить к Criteria еще и скоупинг, только не для селект запросов, но и для всех остальных. Итого выйдет нечто подобное: $this->postRepository->pushScope(new ForUserOnlyScope()); $this->postRepository->remove($id); // DELETE FROM posts WHERE user_id = 1 AND id = 1 Ну а чтобы админ мог удалять все, будет нечто подобное: if (! $user->inRole('admin')) { $this->postRepository->pushScope(new ForUserOnlyScope()); } $this->postRepository->remove($id); // DELETE FROM posts WHERE id = 1 На мой взгляд так куда прозрачнее, нежели это городить внутри репозитория.

@fes0r а если с реквеста данные идут? То persist и flush прямо в контроллере фигачить?

@fes0r а если с реквеста данные идут? То persist и flush прямо в контроллере фигачить?

разберись что делают эти самые persist и flush

и ответишь на свой вопрос

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

не являются, разные сущности ведь

не являются, разные сущности ведь

назови мне две из них

ну возьми к примеру посты и задачи, 2 таблицы у которых есть user_id

ну

2 репозитория

в каждом добавляются условия

это совершенно разные сущности которые могут даже к разным контекстам принадлежать

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

> в каждом добавляются условия типа того if (! $user->inRole('admin')) ... ? я на всякий уточняю, мне кажется это дикость, ведь 3-15 строчек будут повторяется везде )

проверку прав запихни в воутеры

@fes0r persist делает подготовку данных, а flush коммитит в бд?

@fes0r persist делает подготовку данных, а flush коммитит в бд?

ответ неверный

Есть что на русском почитать на эту тему?

проверку прав запихни в воутеры

роутеры?

An entity can be made persistent by passing it to the EntityManager#persist($entity) method. By applying the persist operation on some entity, that entity becomes MANAGED, which means that its persistence is from now on managed by an EntityManager. 

роутеры?

забыл что мы не про симфони, там воутеры есть

ERROR: S client not available

Даже хз как верно перевести. Сущность становится управляемой энтити менеджером?

проверка прав - это не относится к запросам

Даже хз как верно перевести. Сущность становится управляемой энтити менеджером?

да, а теперь подумай что это означает

> в каждом добавляются условия типа того if (! $user->inRole('admin')) ... ? я на всякий уточняю, мне кажется это дикость, ведь 3-15 строчек будут повторяется везде )

а как эти строчки относятся к запросу?

Видимо это означает что там транзакция стартует куда и попадет эта операция

Видимо это означает что там транзакция стартует куда и попадет эта операция

нет

почитай теперь про flush

если очень упрощенно: - все сущности лежат в unit of work (UoW) - UoW знает какое состояние было у сущностей в момент когда оно впервые о них узнало - когда ты делаешь persist для новой сущности, у тебя сущность добавляется в общую кучу. Но так как для этой сущности ничего ранее небыло то мы просто записываем ее в очередь на вставку. - когда ты делаешь persist для сущности которая уже у тебя была и ты достал ее через UoW - оно смотри что "а так у меня она уже есть" и больше ничего не делает. - когда ты делаешь flush то доктрина берет и делает diff всего состояния которое оно хранить и на основе этого формирует пачку sql запросов

идея в том что бы ты работал с базой как если бы у тебя был просто InMemoryRepository

типа достал объект по ссылке и ничего явно сохранять не надо

а как эти строчки относятся к запросу?

хмммм, ты немного отрезвил меня. Немного отойдем в сторону от удаления и апдейта. Что если забить на Criteria и сделать вот так в контроллере: if ($user->inRole('admin')) { $posts = $this->postRepository->all(); } elseif ($user->inRole('publisher')) { $posts = $this->postRepository->findPostByPublisherId($publisherId); }

Не вдавайся в смысл, здесь интересен другой подход. Вместо глобальной критерии-класса, сделать отдельный метод в репе и затем вызвать его, если роль подходит.

да, как-то так

Вроде как даже прозрачнее.

ну в этим и идея, оно просто и прозрачно. Да, примитично и не слишком интересно

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

Да-да, я это и хотел. Черт побери, как же иногда бывает глаз замылен! Спасибо :)

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

И похер, что иф будет в 3-5 местах.

ага

Sergey получается что при условии что энтити описано правильно мне не стоит особо парится о том как работает операция вставки. Доктрина сама знает как правильно вставить

Sergey получается что при условии что энтити описано правильно мне не стоит особо парится о том как работает операция вставки. Доктрина сама знает как правильно вставить

тип того, но не могу сказать что там нет багов)

пару месяцев назад был баг что мол делаешь у коллекции clear, делаешь 2 раза flush и оно отчищается два раза

но это редкие кейсы

Что означает слово консистентность?

со вставкой просто сущностей все хорошо

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

читай википедию

видишь непонятное слово - идешь туда)

Понял. Спс

В общем вся сила доктрины как раз в UoW как я понимаю теперь

Двигаюсь от bitrix->laravel->symfony. Простите за нубские вопросы :)