Итоговый проект: слой данных блога — посты, комментарии, теги, транзакции

Итоговый gorm проект начинается не с кода, а с инвентаризации: что вообще должен уметь слой данных go-приложения-блога. Список получается короткий и очень знакомый: показать ленту опубликованных постов постранично; открыть один пост вместе с автором, комментариями и тегами; создать пост и сразу приклеить к нему теги — так, чтобы половина операции не могла уцелеть отдельно от другой; спрятать пост, не стирая его с диска; вернуть спрятанное; и не обрушиваться при каждом запуске. Это и есть нижний этаж приложения: сервисы и хендлеры дёргают его через интерфейс, а он разговаривает с базой. Двадцать четыре урока дали все детали по отдельности — модели, миграции, удаление, связи, транзакции, пагинация, скоупы, тесты. Сегодня мы не переобъясняем ни одну из них: мы расставляем их по рабочим местам в одном проекте. Схема блога уложится в пять таблиц и четыре модели, Repository — в один интерфейс и одну gorm-реализацию, тесты — в тот же каркас, что вы собирали в прошлом уроке для списка задач. Каждый фрагмент кода снабжён пометкой, из какого урока он приехал: так проект работает дважды — как готовый слой данных и как шпаргалка по всему курсу. Если какая-то деталь кажется чужой — вернитесь по пометке, освежите её и возвращайтесь: финал не прощает пропусков, но и не требует ничего держать в голове насильно.

Начнём со схемы блога — на бумаге, до всякого кода. Четыре сущности и одна join-таблица. Author — автор: id и имя, больше ничего, потому что профиль пользователя нам не нужен, а принадлежность поста — нужна. Post — центральная сущность: заголовок, уникальный slug-адрес, тело, флаг published для черновиков, время создания и внешний ключ author_id — он покажет связь принадлежности из одиннадцатого урока. Comment — комментарий: тело, имя комментатора и post_id, обратная сторона той же пары, но уже один-ко-многим из двенадцатого урока: у поста много комментариев, у каждого комментария один пост. Tag — тег с уникальным именем: один тег живёт у многих постов, и у каждого поста много тегов — это many-to-many из тринадцатого урока, и для него GORM заведёт пятую таблицу post_tags с колонками post_id и tag_id. И одна не-очевидная деталь, которая делает блог блогом: DeletedAt у поста. Удалённая публикация не должна исчезать физически — её возвращают из корзины, её осталось бы видно в админке — поэтому посты удаляются мягко, приёмом девятого урока, а колонка deleted_at получает индекс, потому что фильтр по ней стоит в каждом втором запросе. Обратите внимание, чего в схеме нет: отдельной таблицы «черновики» — черновик это published равный false; таблицы «просмотры» — не наш уровень; категорий — теги их заменяют. Схема блога — это всегда минус сущностей, а не плюс: каждая лишняя таблица — это лишний JOIN, лишняя миграция и лишний тест.

Пройдём по связям, не переобъясняя механику одиннадцатого-тринадцатого уроков — только то, как она легла в схему блога. Связь принадлежности живёт там, где внешний ключ: у поста есть AuthorID, значит пост принадлежит автору, а поле Author даёт GORM понять, к какой таблице идти. Важно, что ключ объявлен явно: без AuthorID связь принадлежности была бы догадкой, а с ним — контрактом. В паре пост-комментарий ключ лежит у комментария: PostID. Со стороны поста это выглядит как has many — поле Comments описывает «у меня много комментариев», а GORM сам догадывается о таблице и колонке по именам Post и Comment. Ничего магического: если бы поле комментария называлось иначе, пришлось бы подсказать тегом — и это было в двенадцатом уроке. Наконец, m2m теги: поле Tags с указанием join-таблицы post_tags. Почему именно многие-ко-многим, а не has many с одной связкой? Потому что тег — разделяемый ресурс: «go» вешают сто постов, и хранить сто копий тега — путь к рассинхрону; join-таблица держит только пары идентификаторов, а имя тега существует в одном экземпляре. Три вида связей закрывают практически любую предметную область: принадлежность — для «чей это», один-ко-многим — для «у кого сколько», многие-ко-многим — для «что пересекается». Блог использовал все три, и ни одну не пришлось подпиливать напильником — это главный признак того, что связи спроектированы верно.

Свяжем проект с десятым уроком про Raw и Exec: полезно видеть, что GORM делает вместо вас, потому что однажды вам придётся писать это руками — в отчёте, в миграции данных, в запросе, который ORM выразит неуклюже. Лента — это цепочка из двух соединений: posts к authors по ключу принадлежности, плюс фильтры — опубликовано, не удалено — и сортировка с постраничными границами. Создание поста с тегами — пачка INSERT-ов: сам пост, теги, которых не было, и строки в post_tags, причём между первым и последним INSERT-ом нельзя позволить базе остаться наполовину заполненной — вот почему следующая операция уедет в транзакцию. Мягкое удаление руками — вообще не DELETE, а UPDATE с условием, что строка ещё не спрятана. Ниже — след, который оставляет наш Repository, если бы его писал человек без ORM. Сравните с кодом ниже по уроку: разница не в объёме, а в том, кто отвечает за корректность колонок, экранирование и диалект. ORM берёт рутину на себя, но цена — вы обязаны понимать, какой SQL он соберёт из ваших цепочек, иначе однажды поймаете скан таблицы там, где ждали точечный поиск по индексу. Десятый урок показал, как заглянуть под капот через Raw; здесь достаточно взгляда на текст запроса глазами.

Схема есть — теперь её рабочая обёртка. Слой Repository мы строим точно по канону прошлого урока: структура с закрытым полем *gorm.DB, конструктор, методы-операции — но с одним важным усилением, которого не было у репозитория задач из прошлого урока. Мы объявим интерфейс PostRepo отдельно от реализации: пять методов, каждый — операция блога, а не обёртка над вызовом GORM. Create принимает пост и список имён тегов — потому что «создать пост с тегами» это одна бизнес-операция, и сервис не должен знать, что внутри неё транзакция. BySlug возвращает пост со всеми связями — потому что страница поста всегда рисует автора, комментарии и теги. Feed возвращает и страницу, и общий счётчик — потому что пагинации без знания общего числа постов не бывает. SoftDelete возвращает счётчик затронутых строк — приём из репозитория задач: промах по несуществующему слагу это ноль без ошибки, и пусть решает сервис, что с ним делать. Зачем интерфейс, если реализация одна? Шов из прошлого урока: тесты сервиса получат мок этого интерфейса, тесты самого репозитория будут гонять настоящую базу, а публикация — не знать ни того ни другого. Конструктор возвращает именно интерфейс: потребители зависят от контракта, а не от конкретной структуры — это и есть слой данных go-приложения, отделённый от всего остального.

Самая важная операция проекта — Create, и она же — главный аргумент за транзакции из пятнадцатого урока. Операция многошаговая: вставить пост, для каждого имени тега найти существующий или создать новый, вставить связку в post_tags. Между шагами всё, что угодно может пойти не так: слаг оказался занят, имя тега нарушило уникальность, соединение оборвалось посреди пачки. Без транзакции это оставляет мусор — пост без тегов, теги без поста, полупустые связки; с транзакцией — или всё, или ничего. Обёртка db.Transaction принимает замыкание и управляет судьбой операций за вас: вернули nil — COMMIT, вернули ошибку — Rollback, и неважно, на каком шаге вы спохватились. Внутри замыкания работаем не с r.db, а с tx — тем же типом, но связанным с транзакцией; фабрика тегов через Where и FirstOrCreate находит существующий тег или создаёт новый, а Association с Append вставляет строку в join-таблицу — механика тринадцатого урока в чистом виде. Одна честная оговорка: FirstOrCreate под конкуренцией — не атомарная операция; два запроса, создающих один новый тег одновременно, разойдутся так, что один получит ошибку уникальности — и это правильно: его транзакция откатится целиком, а клиент попробует ещё раз. Ловим это на верхнем уровне, а не ломаем транзакцию хитростями. Всё остальное — забота замыкания: оно либо доводит операцию до конца, либо стирает её следы.

Удаление в блоге — самое коварное место, и мягкое удаление девятого урока здесь не украшение, а необходимость: публикацию может прятать редактор, а автор через час попросит её вернуть. Наш SoftDelete — это Delete по слагу, но для модели с DeletedAt GORM развернёт его в UPDATE: строка остаётся в таблице, колонка deleted_at получает отметку времени, а все обычные запросы — и наши, и чужие — перестают её видеть, потому что фильтр deleted_at IS NULL GORM добавляет к каждому чтению автоматически, без единого условия с вашей стороны. Отсюда два следствия, которые стоит проговорить. Первое: BySlug удалённого поста вернёт знакомую ошибку отсутствия записи из шестого урока — для читателя спрятанный пост неотличим от несуществующего, и это ровно то поведение, которое нужно ленте и страницам. Второе: строка никуда не делась, а значит её можно вернуть — Restore вызывает Unscoped, пропускающий автоматический фильтр, и пишет в deleted_at нулевое значение. Пара SoftDelete-Restore стоит четырёх строк и закрывает целый класс обращений «верните, пожалуйста, тот пост». А вот чего мягкое удаление не делает — не трогает чужие строки: комментарии спрятанного поста остаются в своей таблице, связки в post_tags тоже. Это не баг, а семантика операции: UPDATE одной таблицы. Что с ними делать — вопрос политики блога, и мы разберём его в ловушках ниже.

Лента — самое читаемое место любого блога, и соберём мы её из двух тем: скоупов девятнадцатого урока и пагинации семнадцатого. Скоуп — это именованный кусочек условия в виде функции, принимающей и возвращающей *gorm.DB: Published — только опубликованные, Draft — только черновики, Page — границы страницы с защитными ограничениями. Композиция — их сила: Scopes принимает их списком, и условия складываются в один запрос; завтра понадобится «черновики конкретного автора» — напишется третьим скоупом, а не четвёртой копией WHERE. Page как функция высшего порядка возвращает замыкание: Feed вызывает Scopes(Published, Page(page, perPage)), а замыкание уже ограничивает границы — страница меньше единицы становится первой, размер страницы больше сотни урезается до разумного. Запросы пользователя — не место для доверия. Сам Feed делает два запроса от одной базы: сначала Count по опубликованным — чтобы вернуть total, без которого пагинация не нарисует страницы; затем Find с теми же скоупами, границами и сортировкой по времени создания. Две независимые цепочки от r.db — условия не перетекают из одной в другую, это важная гигиена из урока про чтение. Мягкое удаление здесь участвует молча: DeletedAt в модели добавляет свой фильтр к обоим запросам, и спрятанные посты в ленту не попадают без единого упоминания.

Тестовый слой проекта — это ровно каркас двадцать четвёртого урока, переезжающий на новую схему без переделок: база на тест с одним соединением, фабрика с осмысленными дефолтами и модификаторами, сабтесты по таблице ожиданий. Меняются только персонажи: вместо TodoItemRepo — PostRepo, вместо makeTask — makePost, вместо одной таблицы — пять. Наша фабрика создаёт пост через сам репозиторий — это не лень, а честность: тест проверяет то, что увидит продакшн, включая транзакцию Create. Черновик или публикация — модификатором, как дедлайн у фабрики задач. Единственная новая дисциплина — слаги: они уникальны на весь прогон, поэтому каждый сабтест использует свои, а если накроете сабтесты транзакционным пузырём newTx — сможете не думать об этом вовсе, канон прошлого урока остался при вас. Что проверяем: Create с тегами — что join-строки легли и теги выгрузились вместе с постом; SoftDelete-Restore — полный цикл спрятать-не найти-вернуть; Feed — что черновики и спрятанные посты не просачиваются, счётчик сходится со страницей. Это минимальный набор, при котором рефакторинг репозитория перестаёт быть прыжком с парашютом: сломаете автоматический фильтр мягкого удаления или потеряете транзакцию — тесты это покажут раньше пользователей.

Пройдём по курсу ещё раз — теперь каждая строка этого проекта имеет адрес. Первый урок объяснил, зачем ORM и когда без него чище; второй — подключение и пул соединений, на котором держится база на тест; третий — модели и соглашения, из которых выросли наши четыре структуры; четвёртый — миграции, что собрали пять таблиц; пятый — Create с его привычками, шестой — чтение с ошибкой отсутствия записи, седьмой — Where, из которого выросли скоупы, восьмой — обновления со счётчиком строк, что вернул нам SoftDelete. Девятый дал мягкое удаление — DeletedAt в модели блога; десятый — Raw, чтобы читать SQL-следы глазами; одиннадцатый-тринадцатый — три вида связей, скелет всей схемы; четырнадцатый — Preload, что выгрузил автора, комментарии и теги одним BySlug. Пятнадцатый — транзакции, на которых стоит Create; шестнадцатый — хуки жизненного цикла, куда проект созреет вешать слагогенерацию; семнадцатый — пагинация, что стала лентой; восемнадцатый — индексы, что подскажут частичное решение для слагов; девятнадцатый — скоупы, что собрали Published и Draft; двадцатый — builder-стиль для динамических фильтров, если блогу понадобится поиск; двадцать первый — NULL и указатели, двадцать второй — пользовательские типы, когда появятся метаданные поста; двадцать третий — диалекты, чтобы проект переехал с SQLite на Postgres без переписывания; двадцать четвёртый — тесты, что сегодня прикрывали спину. Это и есть слой данных go-приложения в сборке — и ваш gorm проект как портфолио.