тут такой момент что repository.findXXX и query builder – они все ориентированы на работу с entity. вариант leftJoinAndMapMany для подзапросов есть:

leftJoinAndMapMany(mapToProperty: string, subQueryFactory: (qb: SelectQueryBuilder<any>) => SelectQueryBuilder<any>, alias: string, condition?: string, parameters?: ObjectLiteral): this;

но тут надо понимать что вложенный запрос – это тоже query builder и он хочет выбирать из сущностей… всё крутится вокруг сущностей…

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

есть ещё вариант – сущности не обязаны работать только с таблицами, есть ещё @ViewEntity – можно сделать вьюху с подзапросом, взять её результат как такую «промежуточную» сущность и замэпить её в leftJoinAndMapMany если никак иначе не выходит…

@constb цель вообще следующая: нужно получить определенные поля (не все) с нескольких таблиц. Но при выборе определенных полей в select вывод возможен только в виде строк (не сущности), то есть getRawMany. Возможно ли в случае вывода определенных полей вывести ответ в виде некой сущности а не набора строк? Что бы вы посоветовали в этом случае?

на SelectQueryBuilder вложенного запроса, насколько я догадываюсь, обязательно надо вызвать from и передать туда сущность, с которой выбирает вложенный запрос…

я ещё сейчас подумал, что часто малоопытные программисты берутся за вложенные запросы чтобы сделать условия выборки на связанной сущности… на всякий пожарный – если это такой случай, то для него на самом деле не нужно делать вложенный запрос… джойн – это картезианское умножение, условия можно описать просто в where…

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

сущность в typeorm всегда выбирается целиком. причина в том как работает save() – он открывает транзакцию и делает select. потом сравнивает поля и сохраняет только изменения (или делает insert если select ничего не вернул)

понятное дело, что если сущность выбрана не целиком, а отдельными полями, то save запишет NULL во все поля которые не были выбраны… 🙂

так что тут выбор – либо работа с целыми сущностями либо с raw-объектами если там какие-то времянки…

я имел в виду создать доп сущность (не полную) и использовать ее только для вывода данных в конкретном случае, в остальных использовать основную сущность. Да, это даже звучит на самом деле не очень)))) просто это то что приходило на ум

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

тут надо ещё задаться вопросом – зачем так делать? это оптимизация какая-то? или просто имеющиеся сущности «не ложатся» на требуемую логику работы запроса?

всё это вообще для оптимизации запроса, сейчас у меня запрос затрагивающий 9 таблиц, и он требует порядка 5 секунд на выполнение, что ни куда не годится. Я пробовал выполнить запрос достающий только нужные мне поля а не все сущности этих таблиц целиком, и да, он работает на порядок быстрее (порядка 300 милисекунд на моей локальной машине), но возвращает строки, что конечно не удобно)

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

потому что ради оптимизации (если таковая вообще оправдана и что-то даёт) проще руками написать sql запрос, дёрнуть его с entityManager.query(), а потом руками переформатировать ответ под нужный формат… если такое не нужно делать постоянно – вполне рабочий вариант…

я весь день сегодня пытался найти это решение))

5 секунд – это дофига! там блобы что ли в базе лежат? 🙂

что за блобы?)

да, 5 секунд это просто непрелично дофига)

или может где-то индексов не хватает? можно включить TYPEORM_LOGGING=1 и взять из консоли запрос который orm генерирует и попробовать сделать на него explain. возможно где-то тупо не хватает индекса…

и это на сервере, на моей машине это от 10 до 30 секунд)))

вроде индексы есть, но я перепроверю

есть такой тип поля BLOB. вообще TEXT – это тоже блоб… надо с ними осторожно, если в строках там текста на мегабайты, то это будет сильно небыстро на любой машине 🙂