Doctrine ORM не рекомендует частичную выборку, каковы альтернативы?

Question

[Rukis]

Если запросом ограничить набор полей, например:

$em->createQuery("select u.id, u.name from MyApp\Domain\User u")->getResult();

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

В доке https://www.doctrine-project.org/projects/doctrine... объясняется почему и предлагается если очень нужно использовать partial:

$em->createQuery("select partial u.{id, name} from MyApp\Domain\User u")->getResult();

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

Понятно, что получить только часть объекта в некоторых случаях чревато проблемами, но вот, к примеру, есть типичная задача: вывести список постов с указанием автора. Нам понадобятся у Post поля id и title, и еще у User поля name, post_id. Выбирать всё - очень не рационально, ведь поле с текстом одного лишь поста объемнее чем необходимые нам поля всех записей суммарно. Это упрощенный пример, суть ситуации в том, что выбирать все поля - не вариант.

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

Предлагается ли Doctrine решение этой проблемы или какова в общем практика?

Answer 1

[Дмитрий]

Это не то, что вам нужно? https://www.doctrine-project.org/projects/doctrine...

Comments

[Rukis]

Дмитрий
Попробовал ResultSetMappingBuilder, казалось бы то что нужно, но, почему то маппер оставляет в результатах по одной родительской сущности для каждой связанной. То есть, например, если мы сджойнили посты с авторами и получили 10 постов от 3 авторов, то после маппинга остается 3 поста, по одному на автора. Так же проблема, если внешний ключ null, в этом случае получаем null вместо родительской сущности.

Answer 2

[Flying]

А почему не работает с join? По-идее никаких ограничений в этом аспекте быть не должно.

Если вам нужны не все поля или хочется оптимизировать запрос так чтобы он обязательно вытаскивал не всё - то лучше строить отдельный запрос и вытаскивать только нужные данные как данные, а не как entities. В конечном итоге вам ничто не может помешать в своём custom repository сделать запрос на данные и насоздавать entities, заполненных этими данными. В большинстве случаев всё-таки содержимое одной строки базы данных не настолько увеличивает размер выборки как количество строк самой выборки. Т.е. выбрать, условно, 20 строк с текстами постов скорее всего будет быстрее чем 10к постов без их текстов.

Если же вам настолько важно выбирать сущности, но не выбирать значения полей (к примеру у вас каждый Post - это книга на несколько мегабайт текста, кто знает?) - можно вынести текст Post'а в отдельную сущность и использовать `OneToOne` отношение, тогда вы сможете использовать преимущества lazy загрузки связей в Doctrine и не выбирать тексты если они не нужны.

Comments

[Rukis]

Flying

А почему не работает с join?

Действительно, оказалось я не так понял синтаксис, похоже что всё работает. Спасибо.

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

[Flying]

Думаю что решение, как обычно, зависит от задачи. Сама по себе Doctrine, конечно, построена в первую очередь вокруг Identity Map и Data Mapper, но при этом есть целый класс задач (к примеру запросы с аггрегацией) для которых нормально получать данные в виде простых массивов. Т.е. если вам нужна именно выборка данных как таковая и не требуется их модификация или выборка связей - вполне нормально использовать и entities и запросы и partials. Если же требуется модификация - то, конечно, лучше entities.