Comments 29
На мой взгляд, сила Go в простоте. И это выражается, например, в том, что в Go принято писать запросы на голом SQL (ORM не в чести). Это и преимущество, и источник дополнительных трудностей.
Кем принято, если не секрет? Насколько я вижу — у gorm, к примеру, очень активная и большая аудитория.
Но, по разным причинам, в Go чуть меньше распространены orm.
А в целом, у постгри много функциональности, которая слабо покрывается orm'ками: мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по json (а в 12 версию закоммитили jsonpath www.postgresql.org/docs/12/datatype-json.html#DATATYPE-JSONPATH) и большое кол-во других вещей, которые делают использование orm неразумным.
orm-холивар предлагаю не разводить. Отличный вопрос, мне понравился, спасибо!)
мощная индексация по json
Стоит обратить внимание, что по json просто нельзя собрать статистику.
А база, планер которой работает по весовой схеме, просто не может нормально работать без статистики.
Но надеюсь скоро исправят, здесь smagen писал: http://akorotkov.github.io/blog/2015/09/07/jsonb_statistics/ для 10-ки точно еще актуально.
мощные cte, насыщенная система типов, функции для работы индексами, мощная индексация по jsonПлюс замечательный PL/pgSQL. Мы так вообще отказались от идеи разрешать приложениям лезть в базу с запросами напрямую, только через API, благо и JDBC, и psycopg2 умеют в callable statements/procedures. В результате вся логика изолирована, больше не надо заворачивать семантику в строку (ура!), можно вообще не париться насчет кавычек и экранирования (тайпчекер постгреса сам проверит корректность аргументов), многие вещи можно фиксить в продакшне без пересборки и перезапуска приложений и пр.
Transaction Mode и Prepared Statements это известная проблема, мы просто запретили их на клиенте через
prepareThreshold=0
.github.com/lib/pq — pure Go Postgres driver for database/sql. Этот драйвер долгое время оставался стандартом по умолчанию. Но на сегодняшний день он потерял свою актуальность и не развивается автором.
С чего вы это взяли? Кодовая база обновляется, последние обновления несколько дней назад.
На Гитхабе никакой информации о прекращении поддержки нет, да и авторов там не один.
Кроме примера из треда, могу еще вот такой PR показать https://github.com/lib/pq/pull/714. О том, что библиотека заброшена пишут даже люди имеющие статус Collaborator.
Основными людьми, поддерживающими жизнь в библиотеке остаются ребята из cockroachdb. Но, например mjibson пишет
It is indeed sad this has no active maintainers. Open source has its problems.
I don't have permissions to grant permissions so I'm not able to do anything. A few of us from cockroach just asked the last time this was a problem and they gave us commit here. We just keep limping along.
Мне кажется, правильным решением будет пометить библиотеку как deprecated, заархивировать проект и забыть о нём. pgx давно обогнал. А с 4 версии станет совсем хорошо)
github.com/jackc/pgx — именно этот драйвер вы хотите использовать.
Хммм… а GORM использует github.com/lib/pq. Интересно, почему не перешли.
С другой стортоны, этот же кактус заставляет лучше и глубже разбираться в том, как все работает внутри, что явно плюс!
При штатном режиме работы базы и приложения пул соединений в Go позволяет не порождать новые соединения к базе. А вот при малейшей деградации базы данных пул соединений на стороне приложения исчерпывается и кол-во порождаемых соединений на единицу времени в разы возрастает.
А можете прояснить, какая тут причинно-следственная связь?
Потенциальные SQL-уязвимости. Разработчик может забыть или некорректно сделать экранирование.
Вероятность этого остается в pgx. Дело в том, что pgx честно делает Simple Query внутри себя, выполняя экранирование аргументов.
github.com/jackc/pgx/blob/0151aeb3077d63ed90110bc083521f709a5d4fef/query.go#L524
Если в этой функции пойдет что-то не так, то это прямой путь к уязвимостям.
lib/pq делает иначе. При указании в connection string параметра binary_parameters=yes драйвер отправит один запрос, в котором сначала идет Parse query string, затем Bind параметров в бинарном виде.
github.com/lib/pq/blob/master/conn.go#L835
Видно, что далее драйвер честно читает Parse и Bind response от базы, как в сценарии с Extended Query.
Это позволяет разработчику или драйверу не собирать запрос в строку самостоятельно, а передать это все базе.
Как преимущество, с simple query меньше запросов в сеть и ниже latency)
Так как мы работу с базой делаем сразу отдельным слоем (что-то вроде паттерна repository, но без фанатизма), то необходимости в ORM не возникает. Собственно, из-за того, что gopg чуть переусложнена, не хочется её использова. Ну и опыта с pgx просто больше)
Как работать с Postgres в Go: практики, особенности, нюансы