подскажите как лучше сделать, есть 2 сущности Author и Post. Надо связать их A one-to-many P, но при этом маппинг Post нельзя трогать, он в стороннем бандле.

можно ключевых слов накинуть и я погуглю

может так? http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#one-to- many-unidirectional-with-join-table

> маппинг Post нельзя трогать, он в стороннем бандле. эм... переопредели из своего

тебе ж явно нужна будет связь пост -> автор

возможно связь автор -> посты не нужна даже

тебе ж явно нужна будет связь пост -> автор

мне нужна будет связь автор -> посты. Остально не важно. Хочу получать всех авторов и их посты

хотя может мне вообще маппинг не нужен?

а мой варинат же норм?

чем моя одностороняя связь плоха?

чем моя одностороняя связь плоха?

какая то мани-ту-мани связь

ссылка поломалась

https://goo.gl/Hr4kQy

во

мне нужна будет связь автор -> посты. Остально не важно. Хочу получать всех авторов и их посты

Для этого тебе связь со стороны автора не нужна. Это делается методом в репозитории. Связь OneToMany - это сахарок, который заставляет доктрину вращаться медленее.

@fes0r Поправь меня, если я неправ.

@fes0r Поправь меня, если я неправ.

совершенно верно

я тупанул

во первых это 100500 запросов, если захочется связь дернуть

бес попутал)

простите

во первых это 100500 запросов, если захочется связь дернуть

Это тоже нет, ЕМНИП. 100500 запросов будет, если ты сделаешь там связь EAGER, а потом будешь у каждого автора докапываться до постов.

Это тоже нет, ЕМНИП. 100500 запросов будет, если ты сделаешь там связь EAGER, а потом будешь у каждого автора докапываться до постов.

емнип?

Если Мне Не Изменяет Память.

Типа As Far As I Know (AFAIK)

ну смотри, если я достану всех авторов и потом в цикле getPosts()

по идеи же каждый раз дергать будет?

Нет, смотри. Есть три ситуации в которых будет один запрос:

или сразу подгрузит?

1. Если ты указал fetch=EAGER (я, извини, раньше тупанул - там выше LAZY имел в виду). 2. Если ты указал при построении запроса setFetchMode для сущности поста как EAGER (тот же EAGER, только в рамках одного запроса). 3. Если ты сделал select и join связи типа такого: ->select(['a', 'p']) ->leftJoin('a.posts', 'p') В этих трёх случаях будет только один запрос. Поле $posts у автора будет заполнено сразу после него объектами постов.

1. Если ты указал fetch=EAGER (я, извини, раньше тупанул - там выше LAZY имел в виду). 2. Если ты указал при построении запроса setFetchMode для сущности поста как EAGER (тот же EAGER, только в рамках одного запроса). 3. Если ты сделал select и join связи типа такого: ->select(['a', 'p']) ->leftJoin('a.posts', 'p') В этих трёх случаях будет только один запрос. Поле $posts у автора будет заполнено сразу после него объектами постов.

3 вариант это в репозитории же?)

В остальных у тебя будут запрошены из БД только авторы, а при каждой попытке получить все посты из коллекции $posts будет генериться новый запрос. От каждого автора.

В остальных у тебя будут запрошены из БД только авторы, а при каждой попытке получить все посты из коллекции $posts будет генериться новый запрос. От каждого автора.

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

3 вариант это в репозитории же?)

2 и 3 делается в репозитории. 1 - в маппинге. Но fetch=EAGER надо очень с умом применять. Если ты решил, что он тебе нужен - возможно, он тебе не нужен, а стоит как-то денормализовать данные.

2 и 3 делается в репозитории. 1 - в маппинге. Но fetch=EAGER надо очень с умом применять. Если ты решил, что он тебе нужен - возможно, он тебе не нужен, а стоит как-то денормализовать данные.

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

Для закрепления (я выше ошибся же): - LAZY и EXTRA_LAZY - дополнительные запросы при получении элементов коллекции - EAGER - автоматический join

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

Да. Поэтому у тебя просто будет метод у репозитория, который тебе вернёт, если надо, авторов и их посты одним запросом.

Да. Поэтому у тебя просто будет метод у репозитория, который тебе вернёт, если надо, авторов и их посты одним запросом.

а как вообще такая практика? 1 метод репозитория принимает на вход qb (там же вроде queryBulder строит запрос?) и возвращает qb с частью запроса на выборку авторов, 2 метод принимает qb и добавляет к тему посты и возвращает тоже qb. И так далее.. и потом просто getQuery->fetch или как там.

А откуда берётся первый QueryBuilder, который в первый метод попадает?

И да, можно строить запрос через QB, можно написать DQL. Можно даже по чистому SQL угореть (но зачем?).

И да, можно строить запрос через QB, можно написать DQL. Можно даже по чистому SQL угореть (но зачем?).

в смысле зачем?)

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

А откуда берётся первый QueryBuilder, который в первый метод попадает?

ну допустим, он создается в первом методе getAuthers() а дальше на него пошел вешать, скоупы(это вроде так называется?)

ну допустим, он создается в первом методе getAuthers() а дальше на него пошел вешать, скоупы(это вроде так называется?)

Чот я не очень догоняю полёт мысли.

хм, может я что-то не то придумал, сейчас попробую

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

но вроде же типа того qb.select(a).from(a authors).getQuery().fetch() ?

я с телефона

сори за код в таком виде)

Ну... Что-то типа того. Только скорее getResult(). И да, ты тут выбираешь авторов из самих же авторов :)

Ну... Что-то типа того. Только скорее getResult(). И да, ты тут выбираешь авторов из самих же авторов :)

другими словами, всех авторов?

ДРугими словами запрос бессмысленный.

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

Вот если a.authors на p.authors заменить - тогда смысла больше.

Нет, это не методы репозитория, это методы QueryBuilder. Не путай их.

В методе репозитория ты делаешь что-нибудь типа $qb = $this->createQueryBuilder('a'); И с ним работаешь.

Нет, это не методы репозитория, это методы QueryBuilder. Не путай их.

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

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

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

Если это репозиторий авторов, то он там уже есть - findAll().

Если это репозиторий авторов, то он там уже есть - findAll().

а где, как не там, мне еще писать эти методы

Ну там, да. Я не понял, в чём вопрос-то. Я тебя не призываю дублировать уже имеющуюся функциональность.

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

а идея в том

точнее вопрос, примерно так должен выглядеть репозиторий? AuthorsRepository + findActiveAuthorsWithPost(): Authors [] - createAutherQuery(void): QueryBuilder; - withPost(QB): QueryBuilder qb; - withoutBanned(QB): QueryBuilder qb; внутри публичного метода, просто цепочка вызовов нижних, приватных методов, а потом getQuery.getResult

findAllQueryBuilder() - это "найти весь QueryBuilder"? :) 3 и 4 пункты - это какие-то костыли. Тебе ничего не мешает передать во второй метод параметром флаг, что надо заджойнить посты, например. Или просто отдельный метод, который делает запрос на авторов с постами. В общем, ты придумываешь лишнее, как мне кажется.

Хотя я сам тот ещё мастер лучших практик. Подожди, может тебе кто поумнее ответит.

findAllQueryBuilder() - это "найти весь QueryBuilder"? :) 3 и 4 пункты - это какие-то костыли. Тебе ничего не мешает передать во второй метод параметром флаг, что надо заджойнить посты, например. Или просто отдельный метод, который делает запрос на авторов с постами. В общем, ты придумываешь лишнее, как мне кажется.

название хромает, согласен

ERROR: S client not available

подправил, ну это так набросок. А на счет параметров, не знаю, наверно не охото чтоб метод findActiveAuthorsWithPost разрастался.

но я тоже, тот еще погромист)

а еще вопрос, через qb можно приджойнить таблицу, на которую у сущности нет маппинга?)

ну если связь authors и post в маппинге не указаны

а еще вопрос, через qb можно приджойнить таблицу, на которую у сущности нет маппинга?)

присоединяюсь к вопросу

порой fk напрягают

а еще вопрос, через qb можно приджойнить таблицу, на которую у сущности нет маппинга?)

только через native query

и то не уверен

вообще логика оч простая

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

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

точнее вопрос, примерно так должен выглядеть репозиторий? AuthorsRepository + findActiveAuthorsWithPost(): Authors [] - createAutherQuery(void): QueryBuilder; - withPost(QB): QueryBuilder qb; - withoutBanned(QB): QueryBuilder qb; внутри публичного метода, просто цепочка вызовов нижних, приватных методов, а потом getQuery.getResult

а блин, наркомания какая-то)

а блин, наркомания какая-то)

мне кажется тут пахнет культом карго

что за культ?

загугли

http://simon-says-architecture.com/2011/08/23/repository

описание хорошего репозитория

самое важное почему скинул вот тут: > Returns one object or throws exception… Why? Because we don’t invoke any action on a collection of domain objects. Ever.

в последний месяц я все чаще и чаще соглашаюсь с этим...

самое важное почему скинул вот тут: > Returns one object or throws exception… Why? Because we don’t invoke any action on a collection of domain objects. Ever.

не совсем понял, не производим действий с коллекцией?

самое важное почему скинул вот тут: > Returns one object or throws exception… Why? Because we don’t invoke any action on a collection of domain objects. Ever.

а можно по русски?

> маппинг Post нельзя трогать, он в стороннем бандле. эм... переопредели из своего

маппедсуперкласс?

маппедсуперкласс?

нет

а можно по русски?

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

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

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

ну идея такая

ага

спасибо за разьяснение

во славу CQRS короч

очень логичненько даже вполне себе

жаль, что с symfony-формами придется тогда дополнительно сношаться, писать дата-мапперы, дата-трансформеры.