Жадная загрузка With*

Жадная загрузка (eager loading) — это просьба привезти связанные сущности тем же походом в базу, что и основных. В ent она включается методами вида With* на query-билдере: WithGroups у UserQuery, WithPosts рядом, WithAuthor у запроса постов — по методу на каждое ребро схемы. Документация зовёт эту возможность ent preload и формулирует честно: ассоциированные сущности попадают в поле Edges возвращённых объектов. Важно проговорить то же, что мы говорили про GORM в его четырнадцатом уроке: ленивой загрузки в ent нет вовсе. После обычного All(ctx) поле u.Edges.Groups — nil, и никакого «дочитывания при первом обращении» не произойдёт: ни прокси, ни сессий, ни отложенных запросов — ent не сделает ни одного запроса без вашей команды. Пустое ребро — не баг и не отложенная загрузка, а запрос, которого никогда не было. Отсюда же и диагноз проблемы N+1: она возникает не сама, а из рук — когда вы читаете соседей в цикле, по одному обходу на каждую запись. Жадная загрузка — единственный способ наполнить Edges, и она же — лекарство: вместо N запросов на страницу уезжает фиксированное число выборок. Сколько именно — считаем на следующих блоках, а начнём с самого простого запроса и посмотрим, что окажется внутри.

Откроем сгенерированный blog/ent/user_query.go — на каждое ребро схемы здесь напечатан свой With-метод, и его устройство стоит знать дословно. Сигнатура: func (uq UserQuery) WithGroups(opts ...func(GroupQuery)) UserQuery. Комментарий генератора переводится так: метод просит билдер жадно загрузить узлы, подключённые ребром groups, а необязательные аргументы настраивают билдер запроса этого ребра. Тело короткое: создаётся свежий GroupQuery через GroupClient — (&GroupClient{config: uq.config}).Query(), затем каждая опция из opts применяется к нему, и готовый билдер сохраняется в поле-хранилище withGroups GroupQuery. Именно это поле — переключатель жадности: nil означает «ребро не просили». Три следствия. Первое: опции вариативны — можно передать хоть три функции разом, и все применятся к одному и тому же запросу соседа. Второе: состояние With участвует в Clone() — скопированный билдер уносит with-поля с собой, так что заготовку с загрузкой можно клонировать. Третье: With живут не только на корневых запросах — обход anna.QueryGroups() возвращает тот же *GroupQuery, и WithUsers() на нём работает без оговорок. И ещё одна граница из документации: жадную загрузку поддерживают только SQL-диалекты — гремлиновский бэкенд её не имеет, но нас это не касается. Если вы искали по запросу with ent примеры — сгенерированный код и есть первоисточник: сигнатуры короткие, магии нет.

Самый практичный вопрос жадной загрузки — тариф. Ответ доки прямолинеен: поскольку один запрос может жадно загрузить несколько рёбер, собрать все ассоциации одним JOIN невозможно — ent исполняет дополнительный запрос на каждую связь. В сгенерированном sqlAll это видно построчно: сначала главный SELECT по users через sqlgraph.QueryNodes, затем ранний выход — если len(nodes) == 0, за соседями никто не ходит, пустой странице они не нужны; дальше по каждому ребру с непустым with-полем вызывается свой загрузчик loadGroups, loadPosts, loadFriends — по одному запросу на ребро. Попутно заполняется служебный массив Edges.loadedTypes — по булеву на каждое ребро схемы: он запоминает, что именно вы просили, и сыграет главную роль в OrErr-доступорах ближе к концу урока. Итого тариф: один запрос на родителя плюс один на каждое запрошенное ребро, независимо от числа строк. Двадцать пользователей с группами и постами — три SELECT, а не двадцать один. Здесь курс GORM снова рядом: его четырнадцатый урок разбирал Preload как лечение того же N+1 — один главный запрос плюс IN-выборка на уровень связей. Философия совпадает до забавного: и там, и там ленивой загрузки нет, пустые срезы честные, а N+1 рождается из ручных циклов. Разница в мелочах: в GORM уровень m2m стоит две выборки — сначала join-таблица, потом записи; ent в m2m-шаге объединяет join-таблицу с записями JOIN-ом в одном запросе. Экономия в один запрос на уровень — приятный бонус за графовую архитектуру.

Пустые скобки после WithGroups — не единственная форма. Каждый With-метод принимает вариативный список опций-функций, и это открывает условную With-форму: загрузить не всех соседей, а только нужных. Выглядит так: WithGroups(func(gq *ent.GroupQuery) { gq.Where(group.Name("go-ninja")) }) — внутрь приходит полноценный билдер GroupQuery, и вы можете делать с ним всё, что умеет любой запрос: Where с предикатами из десятого урока, Order для сортировки соседей, Limit для ограничения их числа, Select для проекции колонок. В документации каноничный пример добавляет q.Limit(5) и вложенное q.WithUsers() в одну опцию — жадность настраивается теми же словами, что и обычный запрос. Семантику нужно зафиксировать раз и навсегда: условие применяется к выборке соседей, а не к родителям. Строки родителя не теряются никогда: пользователь, у которого нет go-ninja, вернётся как вернулся — просто с пустым срезом Groups. Это зеркало-противоположность HasGroupsWith из прошлого урока: там фильтр по соседям отбирал строки родителя, здесь — наполняет рёбра подмножеством. Фильтр и загрузка — две разные развилки, и путать их дорого. Ещё два практических штриха. Повторный WithGroups с опциями не суммируется с предыдущим: каждый вызов создаёт свежий GroupQuery и затирает поле — выигрывает последний, опции не складываются. А проекция через q.Select(user.FieldName) не сломает раскладку: ent сам допишет к выбранным колонкам те, что нужны для привязки рёбер — первичный ключ и внешние ключи, — так что короткие проекции соседей безопасны.

У загруженного соседа рёбра тоже пусты — пока не попросите. Вложенная загрузка делается ровно теми же With-методами, только внутри функциональной опции: WithGroups(func(gq *ent.GroupQuery) { gq.WithUsers() }) просит у каждой загруженной группы её участников. Синтаксис не новый — новый только уровень: ent рекурсивно применяет тот же тариф, по одному запросу на ребро каждого уровня. Пользователи с группами и участниками групп — три SELECT: users, группы через group_users, затем участники групп через ту же таблицу связи с другого конца. Глубина не ограничена схемой: WithUsers(func(uq){ uq.WithPosts() }) достроит четвёртый этаж — но каждый этаж стоит свой запрос, поэтому граф загрузки стоит рисовать до кода, а не после жалобы дежурного. Для нашей M2M-пары это возвращает сюжет шестого урока: таблица group_users с двумя NOT NULL ключами и каскадами обслуживает оба направления — WithGroups читает её со стороны пользователя, вложенное WithUsers — со стороны группы, и оба шага выглядят как JOIN с IN-списком. Ещё одно следствие держите в голове при отладке: незагруженное вложенное ребро — это nil, и никакой ошибки при обычном чтении не будет. Обратились к g.Edges.Users без WithUsers — получили nil-срез молча; ошибка NotLoadedError появится только в OrErr-доступорах, о которых ниже. Если страница должна отдавать граф целиком — пользователей, их группы и участников — вложенная загрузка делает это за константное число запросов: один на ребро каждого уровня, и это ровно то, о чём просит любой REST-выпускник и что соберёт вам GraphQL-интеграция автоматически, но об этом в конце урока.

Тизер с девятого урока наконец закрывается. В сгенерированной структуре UserEdges рядом с полями Groups, Posts, Friends живёт служебный массив loadedTypes — по булеву на каждое ребро схемы: sqlAll расставляет их по факту «with-поле непусто». На его основе генерируются безопасные доступоры: GroupsOrErr() ([]Group, error), PostsOrErr(), FriendsOrErr() — по одному на каждое незуникальное ребро. Семантика трёхслойная. Ребро запрошено — доступор вернёт срез, пусть даже пустой: «загрузили, соседей нет» — законный ответ, и он неотличим от «загрузили, соседей много, но фильтр в условной With их отсёк». Ребро не запрошено — NotLoadedError с текстом вида «ent: posts edge was not loaded»: это не ошибка базы, а честное «вы об этом нас не просили», и проверяется она хелпером ent.IsNotLoaded(err). Отдельный случай — уникальные рёбра вроде Post.author: AuthorOrErr() вернёт nil и NotFoundError, если WithAuthor был вызван, а соседа в базе не оказалось — «загрузили, но не нашли»; без вызова — всё тот же NotLoadedError. Разница между nil-срезом и ошибкой — это разница между «пусто, потому что так в данных» и «пусто, потому что вы забыли With»: первый случай — бизнес-логика, второй — баг вызова, и доступоры их разделяют за вас. Читать u.Edges.Groups напрямую по-прежнему можно — но тогда молчаливый nil и NotLoadedError-случай неразличимы; в API-слое берите OrErr, в горячих внутренних циклах — прямое поле. Так вы закрываете последнюю дыру между «запрос вернулся» и «данные на месте».

К чему ведёт вся эта конструкция, лучше всего видно в GraphQL-интеграции entgql — до неё дойдём в двадцать первом уроке, здесь только прицел. Клиент GraphQL запрашивает не таблицы, а граф: пользователей, у них — группы, у групп — участников. Функция CollectFields собирает запрошенные клиентом поля, видит среди них рёберные и превращает каждый в With-вызов нужной глубины — жадная загрузка, построенная автоматически по форме запроса. Всё, что вы сегодня сделали руками — вложенные With, проекции, ограничения числа соседей, — в entgql собирается из документа GraphQL; то, зачем условной With нужна проекция Select, станет очевидно именно там: незапрошенные колонки не хочется возить из базы. Второй виток той же истории — названные рёбра: экспериментальный feature-флаг namedges включает семейство WithNamed, где одно ребро можно загрузить дважды под разными именами с разными условиями — WithNamedComments("published", ...) и WithNamedComments("draft", ...) в одном запросе. Мотивация чисто GraphQL-овская: два алиаса одного ребра с разными аргументами. Названные рёбра отключены по умолчанию и в обычном коде не нужны — обычные With накладываются друг на друга перезаписью поля, а не множатся. Забирайте отсюда главное: With — это не костыль для ORM-задач, а транспортный слой графа, на котором стоит целый стек поверх ent.

Вы умеете привозить граф целиком: рёбра любого типа, условные фильтры на соседей, вложенные уровни и честная диагностика через OrErr. Ограничивать саму страницу пользователей — Limit, Offset и курсорную пагинацию — разберёт двенадцатый урок 12-paginaciya: жадная загрузка сочетается с пагинацией без сюрпризов, но механика страниц — его территория, там же и сортировка. Домашнее задание превратит тариф «запрос на ребро» в пальцевую память: возьмите базу из домашек восьмого урока, перепишите ручной цикл с QueryGroups на WithGroups и посчитайте разницу в логе драйвера. Если понадобится вспомнить, как отбираются сами строки, — фильтры и HasEdge-предикаты остались в десятом уроке, а устройство M2M-таблиц — в шестом. Полный план из 25 уроков — на странице курса.