Как маппить результат запроса бд в структуры со вложенностями Golang?

Question

[John Bjornsen]

Наверняка кто-то уже сталкивался с проблемой маппинга выдачи бд в структуры с вложенной иерархией в языке Го. Проблема у меня следующая - есть постгрес бд, есть драйвер pgx, есть запрос, который запрашивает одну сущность и джоинит к ней еще две. Сущности имеют следующую вложенность Game <- Round <- RoundType и выглядят примерно так:

type Game struct {
    ...
    Rounds []Round
}

type Round struct {
    ...
    RoundType RoundType
}

type RoundType struct {
    ...
}

Сам pgx не предоставляет удобного функционала сканирования результатов выдачи в нужные структуры, поэтому по советам из интернетов я поставил scany, но проблема оказалась в том, что эта либа не умеет маппить результат во вложенные структуры. Можно заэмбеддить одну структуру в другую, но тогда результат маппинга будет плоская структура, а не со вложенностями. Отсюда вопрос тем, кто использует pgx - как вы маппите сложные выдачи бд в структуры с определенным уровнем вложенностей? Я в итоге написал свой маппер для одной из функций, но он получился довольно объемный и в нем легко допустить ошибку, которая не отловится, пока сам не увидишь, что что-то смаппилось не туда, неужели это единственный подход и надо для каждой выдачи писать свой маппер или все таки есть какой то более простой выход из ситуации?

Comments

[Александр Павлюк]

Лучше разделять в коде то, как данные приходят из БД и как они выглядят в бизнес-логике приложения. Использовать для этого разные типы.

Из БД у вас приходит набор строк и столбцов, это все удобно парсить в виде слайса структур, каждая структура в котором представляет собой одну строку. После этого пишется конвертер такой структуры в типы, удобные для бизнес-логики приложения, лучше не писать универсальный маппер, который умеет мапить вообще все, го довольно простой язык и задачи в нем принято решать тоже наиболее простым способом.

[mayton2019]

Ты не ошибся в направлении стрелочек?

Game <- Round <- RoundType
Если читать направление как линк на parent то у тебя типы ранудов - дочки по отношению к игре.

А я-бы сделал так.
Game <- Round -> RoundType
Справочник раундов справа.

[John Bjornsen]

Александр Павлюк, так вот с джоинами выдача получается не 1 строка = 1 сущность, а для одной сущности может быть 5 строк, потому что у игры может быть несколько раундов например. И получается если писать свой маппер, то недостаточно проходить итеративно по строчкам, создавать структуру и класть в слайс, надо еще держать мапку индексов в результативном слайсе уже смапленных структур-игр, чтобы знать, куда положить очередной смапленный раунд. Это еще я не говорю про то, что pgx возвращает результат каждой строки как обезличенный слайс пустых интерфейсов, то есть надо вспомнить какое значение к какому полю относится и еще привести его к гошному типу, обработав ошибки, а таких полей 30+. Все это кажется не столь уж простым и на каждом этапе множатся возможности ошибиться и все это только для одной выдачи :\

[John Bjornsen]

mayton2019, стрелочками выразил вложенность структур - игра, в которой есть слайс раундов, в структурах раундов есть поле типа раунда

[mayton2019]

Сделай по классике.

- 3 таблицы
- games
- rounds
- round_types

Запросы будут содержать join всех таблиц. Insert/Update будут работать в основном по игре и по раундам.

Profit.

[John Bjornsen]

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

[mayton2019]

John Bjornsen, я тебе ничем здесь не помогу. Но я тебе скажу что все эти JPA/Hibernate/Toplink/Linq/DjangoORM
и прочие штуки для маппингов например в других технологиях решают одни проблемы
и превносят другие.

Если ты можешь написать руками SQL запрос то это хорошо. Напиши. Ты будешь контролировать
ситуацию в игре и сможешь добавлять к SQL запросам хинты и переписывать их JOINS так как тебе удобно.
ORM обычно этого дает. И очень часто ORM выставляет разработчика дураком. Особенно начинающего.

[Александр Павлюк]

John Bjornsen,

возвращает результат каждой строки как обезличенный слайс пустых интерфейсов

Я потому и посоветовал в структуры результат сканить, как это в sqlx сделано, например

type Person struct {
    FirstName string `db:"first_name"`
    LastName  string `db:"last_name"`
    Age            int      `db:"age"`
}

people := []Person{}
db.Select(&people, "SELECT * FROM persons")

Тегами в структуре помечаете, как называются колонки в запросе и ставите нужные типы. Исключает возню с интерфейсами.

надо еще держать мапку индексов в результативном слайсе

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

[John Bjornsen]

Александр Павлюк, вот сканить в структуру как в sqlx я могу только простые запросы, собственно так и делаю, а вот с джоинами маппер scany например уже ругается, потому что у двух сущностей есть поле id и он не может это смаппить в плоскую структуру из-за конфликта, а в структуру с вложенностями тупо не умеет. Поэтому наверное да, вы правы, кастомные мапперы это наш путь) просто думал вдруг есть какое то универсальное решение, которое уже отлажено и проверено временем

[Александр Павлюк]

John Bjornsen, так поля-то нужно в запросе алиасить разными именами, само собой

https://learnsql.com/blog/how-to-use-aliases-with-...

[John Bjornsen]

Александр Павлюк, так если по такой логике алиасить поле id у второй сущности например на idSmth, то и в структуре в теге надо будет такое же указать, а если везде алиасить поле айди, то это уже больше на костыли похоже, а ведь там еще могут повторяться другие поля типа name и прочих. Сейчас я просто использую звездочку в запросе и эти поля возвращаются в datagrip с префиксом таблички, которая сджоинилась, но толку от этого все равно не много при маппинге. Но на самом деле я еще не так подробно изучил структуру ответа pgx, возможно смогу из ее недр достать список запрашиваемых полей и через рефлексию как то маппить все это дело, чтобы приблизиться к универсальности и переиспользуемости решения

[Александр Павлюк]

John Bjornsen,

если везде алиасить поле айди, то это уже больше на костыли похоже

Если идет джоин по этому полю и айди одинаковое у нескольких колонок в таблице ответа, то лучше всего запрос составлять так, чтобы в ответе была только одна колонка с айди, это логичнее и данные лишние не бегают по сети. А в структуре можно в теге префикс таблицы как раз указывать, чтобы матчилось на нужную колонку, а неиспользуемые колонки не указывать (вроде для этого опцию нужно включить специальную).

[darst]

John Bjornsen, так в запросе назови их по разному. Например games_id, round_id, и т.д. Так не будет путаницы.

Answer 1

[Виктор Кожухарь]

- Я считаю, что свой кастомный маппер - это отличное решение. Чтобы быть уверенней, обязательно напишите тесты. Как unit, так и интеграционные, например, с помощью testcontainers.

- Можете вместо pgx посмотреть в сторону sqlc. У него совершенно другой подход. Вы пишете запрос со всеми джойнами, а он вам автоматически генерирует код со всеми структурами и функциями. Правда, там по джойнам практически отсутствует документация, но уж погуглите.

- Ну, и если совсем сложно... то... может одним глазком глянуть в сторону ORM? Я никому не расскажу...

Comments

[John Bjornsen]

- Ну вот я все больше убеждаюсь, что все используют кастомные мапперы, значит скорее всего и мне придется)

- по поводу sqlc - к сожалению не могу использовать, потому что у pgx есть солидное преимущество в том, что он поддерживает тот функционал постгри, который не поддерживают ни sqlc ни sqlx и иже с ними.

- неее, орм это харам, если бы хотел на орм писать, то оставался бы на пхп :D

[Виктор Кожухарь]

sqlc - к сожалению не могу использовать

Так используйте оба!
Например, можно использовать паттерн Repository и общаться с базой на более абстрактном уровне. А внутри репозитория в каждой конкретной функции использовать тот инструмент, который подходит для данного конкретного случая

[shurshur]

John Bjornsen,
ORM это не свойство php. ORM это подход к работе с базой, причём даже важнее не то, что ORM позволяет вместо запросов оперировать объектами, а то, что ORM закрывает собой вопрос обслуживания и обновления базы, создания и изменения сущностей, и всё это с довольно небольшим количеством кода. Довольно неплохой подход, во многих языках и фреймворках применяется. Конечно, далеко не серебрянная пуля - иначе бы все переходили на ORM. Но всё же.

[Виктор Кожухарь]

shurshur, Почему современные разработчики не очень любят ORM?
Потому что в самом начале разработки ORM тебе помогает. Но на поздних этапах, а особенно, при рефакторинге, при серьезных изменениях бизнес-логики, ты начинаешь сражаться не только с самими задачами, но и с ORM, которая диктует, навязывает проекту свои строгие правила.

Поэтому, надо всегда понимать, какой инструмент и почему ты выбираешь. И если сомнений нет, все за и против рассмотрены, то нет ничего плохого в использовании ORM, потому что она может очень значительно ускорить разработку при определенных условиях.

[shurshur]

Виктор Кожухарь, я о том и говорю: инструмент используется тогда, когда чётко понимаешь, что он принесёт пользу, несмотря на свои сопутствующие недостатки. Например, при разработке стандартных сайтиков с простой структурой ORM очень даже удобно использовать, особенно если там мильон полей, которые будут только новые изредко добавляться. Ну и опять же, ORM можно совмещать с REST/CRUD.

Но основное против чего я выступал - это в ошибочном смешивании ORM и php. И на основе негативного отношения к php (скорее всего, больше эмоционального, чем практически осмысленного) отрицается и ORM.