Preloading и жадная загрузка — Preload, Joins, N+1 и вложенные загрузки в GORM

Начнём с демистификации. В предыдущих уроках поле-ассоциация при чтении всегда было пустым: Find по спискам возвращал TodoList, у которого Items — пустой срез, Find по комментариям — Comment с нулевым TodoItem. Кто-то ждёт, что GORM «дочитает» связь при первом обращении к полю — так работают ленивые загрузчики в других ORM: прокси-объекты, сессии, магия под капотом. В GORM этого нет ни в каком виде: после SELECT * FROM todo_lists поля заполняются колонками этой самой таблицы, и на этом запрос закончен. Пустой Items — не «отложенная загрузка» и не баг: запроса к todo_items просто никогда не было, срезу неоткуда наполниться. Это осознанный дизайн: GORM не делает ни одного запроса без вашей команды, и каждая выборка в логе — чья-то явная. Читать связь по одной записи вы уже умеете: db.Model(&list).Association("Items").Find(&items) из двенадцатого урока и Preload-тизер из тринадцатого показывали оба направления — belongs to держит ключ у себя, has many у детей, а одиннадцатый урок объясняет, откуда GORM берёт условия. А вот для списка записей Association-подход ломается: одна запись — один запрос, двадцать списков — двадцать запросов. Классическая ловушка называется N+1: один SELECT владельцев плюс по одному на каждую запись. В поиске она так и осталась n+1 problem gorm — и важная оговорка именно для GORM: ORM не создаст N+1 сам, без Preload он вообще не читает связей; N+1 возникает только тогда, когда вы читаете их вручную в цикле. Ниже — как выглядит и то и другое в SQL-следе.

Механика прозаичнее, чем кажется. Метод Preload живёт в chainable_api.go — среди Where и Order, а не среди finisher-ов, и это честная подсказка: сам он ничего не запрашивает. Его тело — одна строка: tx.Statement.Preloads[query] = args. Имя ассоциации и аргументы ложатся в карту Statement.Preloads и ждут своего часа; повторный Preload с тем же именем перезапишет запись карты — последнее условие выигрывает, об этом ловушка ниже. Час настаёт на Find: цепочка колбэков запроса выполняет gorm:query — главный SELECT, — а сразу за ним зарегистрирован gorm:preload из callbacks/preload.go. Сначала parsePreloadMap режет имена по точкам (Items.Comments — уровень Items и вложенный Comments), а запись clause.Associations разворачивает во все прямые связи схемы — ровно как Select(clause.Associations) при каскаде из двенадцатого урока. Затем имена сортируются: sort.Strings с комментарием «avoid random traversal of the map» — порядок загрузки ассоциаций определяется алфавитом, а не порядком ваших вызовов. Дальше preload(): GetIdentityFieldValuesMap собирает значения ключей владельцев из уже прочитанных строк, и строится clause.IN — одна выборка на уровень; для many2many предварительно читается join-таблица, поэтому на уровень уходит две выборки — механика тринадцатого урока. Перед раскладкой поля очищаются — «clean up old values before preloading»: срезы has many и m2m пересоздаются через reflect.MakeSlice (пустой, но НЕ nil), единичные структуры — через reflect.New. Раскладка идёт по identityMap: у каждой загруженной строки читается её ключ, и строка приписывается владельцу, чей ключ совпал; строка без хозяина — ошибка failed to assign association, make sure foreign fields exists. Опечатка в имени — ошибка ErrUnsupportedRelation: «Items: unsupported relations for schema TodoList».

Второй аргумент Preload — условия на выборку ДЕТЕЙ. Inline-условие выглядит как аргументы Where: db.Preload("Items", "status = ?", "done").Find(&lists) — и уедет во второй запрос: WHERE todo_list_id IN (1,2,3) AND status = 'done'. Дока показывает зеркальный пример: Preload("Orders", "state NOT IN (?)", "cancelled") даёт SELECT FROM orders WHERE user_id IN (1,2,3,4) AND state NOT IN ('cancelled') — «it works similar to Inline Conditions», как inline-условия Create. Более гибкая форма — func-условие: вместо строки передаётся func(db gorm.DB) gorm.DB, который получает ВЕСЬ конвейер дочернего запроса и волен добавить не только Where, но и Order, Select, Limit. Доковский пример — сортировка: db.Preload("Orders", func(db gorm.DB) *gorm.DB { return db.Order("orders.amount DESC") }).Find(&users) — след показывает «order by orders.amount DESC»; в исходниках func-условия применяются напрямую к tx, а inline-условия уходят в tx.Where(inlineConds[0], inlineConds[1:]...). Важнейшее правило, которое экономит вечер отладки: условие Preload фильтрует детей, а НЕ владельцев. Семантики INNER JOIN нет: список, у которого не нашлось ни одной выполненной задачи, вернётся — с пустым (но ненулевым) срезом. И вложенный нюанс из доки: условие родителя сужает следующий уровень — если заказы отфильтрованы условием state = 'paid', то их OrderItems не загрузятся: вложенная запись Preload("Orders.OrderItems") катается на родительском запросе, и «unmatched» заказы до третьего уровня не доедут.

Связи канона глубже одного уровня: у списка задачи, у задачи комментарии и теги. Вложенный Preload записывается через точку — db.Preload("Items.Comments").Find(&lists) — и выполняется по уровням: сначала главный запрос списков, затем задачи IN-выборкой по собранным ключам списков, затем комментарии IN-выборкой по собранным ключам задач. Каждый уровень — отдельный запрос, и это важная инварианта: цепочка из трёх уровней — это три запроса при трёх записях и всё те же три запроса при трёх тысячах, тогда как ручной цикл дал бы тысячи. Дока показывает трёхуровневый пример db.Preload("Orders.OrderItems.Product").Preload("CreditCard").Find(&users) — уровни комбинируются в одном вызове с одиночными ассоциациями. Вторая возможность — Preload All: запись clause.Associations разворачивается во все ПРЯМЫЕ ассоциации модели, как и при каскаде удаления из двенадцатого урока. Для TodoList с единственным полем-срезом Items это эквивалент Preload("Items"). Ограничение доки важно запомнить: «clause.Associations won’t preload nested associations, but you can use it with Nested Preloading together» — Preload All не заходит вглубь, но сочетается с явной вложенностью: db.Preload("Items.Comments").Preload(clause.Associations).Find(&lists) загрузит задачи, их комментарии и всё остальное первого уровня. Это удобный дефолт для «страницы всего» с точечными доработками: широкая загрузка одним словом плюс целевые уровни через точку.

У жадной загрузки есть второй сорт — Joins-предзагрузка. Дока разводит их одной фразой: «Preload loads the association data in a separate query, Join Preload will loads association data using left join». Вместо двух поездок — одна: главный SELECT сразу собирает владельца и соседа. Выглядит это как db.Joins("TodoItem").Find(&comments): первым аргументом идёт ИМЯ ПОЛЯ-ассоциации, и GORM отличает Joins-предзагрузку от «сырого» Joins с SQL-строкой — у него первым аргументом идёт условие JOIN, а здесь имя поля. В SELECT появляются колонки соседа с префиксом — TodoItem__id, TodoItem__title, — а LEFT JOIN строится по связи: FROM comments LEFT JOIN todo_items TodoItem ON comments.todo_item_id = TodoItem.id. После чтения сканирование раскладывает префиксные колонки прямо в поле TodoItem каждого комментария — Preload вызывать не нужно. Ограничение доки жёсткое: «Join Preload works with one-to-one relation, e.g: has one, belongs to» — has many и many2many так не загрузишь, JOIN дал бы декартово произведение строк владельцев. Условия передаются вторым аргументом и уезжают в ON: db.Joins("TodoItem", db.Where(&TodoItem{Status: "done"})).Find(&comments) — ON ... AND TodoItem.status = 'done'. Работает и вложенность: db.Joins("TodoItem").Joins("TodoItem.TodoList").Find(&comments) — второй JOIN с алиасом TodoItem__TodoList, ровно как доковский Manager__Company. Держите в голове различие: Joins("JOIN todo_items ...") с сырой строкой — это фильтр владельцев, поля ассоциаций он НЕ заполняет; Joins("TodoItem") по имени поля — предзагрузка.

Тринадцатый урок обронил, что жадная загрузка бывает двух сортов; теперь у вас есть механика обоих. Считайте стоимость. Preload: по одной поездке на уровень (для m2m — две: join-таблица плюс записи), но каждая поездка возвращает компактный набор одной таблицы, дублирования нет, а условия и порядок детей настраиваются свободно. Joins-предзагрузка: одна поездка, но колонки соседа повторяются в каждой строке владельца — при широком соседе ответ раздувается, зато LIMIT-ловушка рукописных JOIN-ов здесь исключена: LIMIT уезжает в главный запрос по владельцам, соседи вклеиваются без ограничений — при ручном JOIN с LIMIT пагинация режет уже склеенные строки, и часть владельцев теряет соседей. Выбор сорта — это выбор по форме связи: belongs to и has one — территория Joins (один запрос, одна запись соседа на строку); срезы has many и many2many — территория Preload, потому что Joins-предзагрузки для них не существует (NOTE доки). Отсюда практическая сетка канона: «комментарий → задача → список» — Joins("TodoItem").Joins("TodoItem.TodoList") одной поездкой; «список → задачи → комментарии и теги» — Preload("Items.Comments").Preload("Items.Tags") отдельными выборками. Смешивать законно: Joins для одно-к-одному хвоста и Preload для срезов живут в одном конвейере, потому что gorm:preload и сканирование JOIN-колонок — разные этапы одного Find. На задачах «вывести и отфильтровать по соседу» выигрывает Joins — фильтр по TodoItem.status ложится прямо в главный запрос; на задачах «выгрузить дерево» выигрывает Preload — данные не дублируются.

Соберём страницу целиком: списки, их задачи, комментарии задач и теги задач. Ручной цикл сделал бы 1 + N списков + M задач + K тегов запросов; preloading делает это пятью SELECT: db.Preload("Items.Comments").Preload("Items.Tags").Find(&lists) — списки; задачи WHERE todo_list_id IN; комментарии WHERE todo_item_id IN; строки join-таблицы todo_tags WHERE todo_item_id IN; теги WHERE tags.id IN. Пять запросов при любом объёме данных — вот цена вопроса, которую обсуждали под меткой n+1 problem gorm. Добавьте clause.Associations, чтобы захватить прямые ассоциации, которые появятся у TodoList позже, — и маршрут переживёт эволюцию модели без правки запроса. Обратное направление читается зеркально: теги со своими задачами — db.Preload("Items").Find(&tags), задача со своим списком — db.Preload("TodoList").First(&item, 4). Прелесть канона в том, что всё уже знакомо: модели и связи — из одиннадцатого, двенадцатого и тринадцатого уроков, чтение одной записи — Association из двенадцатого, а теперь и вся страница собирается одной цепочкой Preload. Сверьте следы с логгером: пять строк SELECT на страницу — норма; если видите десятки одинаковых SELECT с разным todo_list_id — где-то остался ручной цикл.

Жадная загрузка встала на обе ноги: Preload с IN-выборками для срезов, Joins — одним LEFT JOIN для одно-к-одному, вложенные уровни и clause.Associations для широкой выгрузки. Полезно перечитать следы своих запросов: где-то в проекте наверняка живёт ручной цикл, который заменяется одной IN-выборкой, а зеркальные модели канона удобно сверить по одиннадцатому уроку и двенадцатому; join-таблица todo_tags и её двухступенчатое чтение — в тринадцатом уроке; карта курса из 25 уроков — на странице курса. Дальше — надёжность записи: Пятнадцатый урок «Транзакции» покажет, как собрать несколько шагов сохранения в атомарный маршрут через db.Transaction, что происходит при вложенных вызовах, как работают SavePoint и уровни изоляции — и почему Preload внутри транзакции видит те же данные, что и её владелец. Домашка ниже собирает preloading канона в один скрипт.