Comments 11
Это всё круто, но что-то я вангую что там под капотом "любимый" убийца производительности reflect, а значит если сервис испытывает нагрузку, то желательно избегать этого варианта, ну либо заплатить за большее кол-во машин на которых будет запущен Go.
Я тоже сразу такой враппер для себя сам написал давно и так же сразу обнаружил в бенчмарках что он сильно просаживает performance из-за reflect. Вообще Go очень чувствителен в плане производительности к тому, какой именно код мы пишем и как именно.
В pgx есть функции, для скана в структуру/мапу: CollectOneRow/CollectRows + RowToStructByName, RowToMap.
Возможно вы чтото недопонимаете. Сам jackc, создатель pgx указал этот враппер в README своей либы - Pgx. Скорее всего он бы не стал этого делать если бы он был бесполезен и реализовывал существующие методы.
Можете глянуть сами, в конце README файла.
https://github.com/jackc/pgx
а на кой это нужно если уже давно есть sqlc
Прежде чем публиковать, автор, вы хотя бы проверили бы есть ли в pgx уже такой функционал. А как написали выше, он есть.
Рефлексия — это про удобство, но не быстро все же.
Привет, это команда GitVerse! У тебя крутая статья, будем рады видеть тебя в сезоне open source. Для этого просто поставь тег "сезон open source" – и ты участвуешь :)
Удобное сканирование в структуры в связке Go/PgX. Решение проблемы сканирования в PgX. Golang