andrei-polukhin Sep 17 at 07:16

pgdbtemplate — моментальное создание тестовых баз PostgreSQL в Go через шаблоны. Ускоряем тесты в 1.5 раза

Medium

3 min

1.9K

Go * PostgreSQL * Web services testing *

From sandbox

Recovery Mode

Comments 9

anaxita Sep 17 at 08:00

Я что то так и не понял чем это решение отличается от вызова create database from template и drop database в конце?

andrei-polukhin Sep 17 at 12:57

Спасибо за комментарий. Я полагаю, такой вопрос можно поставить ко всем абстракциям / декомпозициям. Разумеется, можно делать все это мануально, однако библиотека делает это безопасно с точки зрения асинхронного программирования, дает четкий интерфейс абстракций (что делать за чем), а также имеет четкие benchmark'и.

К примеру, есть очень edge cases, которые трудно делать мануальными командами - что если template база данных создалась, но подключиться к ней не удается? Ее нужно удалить, а еще сказать пользователю о всех ошибках на этом этапе. Вот примеры: https://github.com/andrei-polukhin/pgdbtemplate/blob/89baa761f6d79ed92fc7c6db77ed60f76a230f32/template_manager.go#L183-L202 и https://github.com/andrei-polukhin/pgdbtemplate/blob/89baa761f6d79ed92fc7c6db77ed60f76a230f32/template_manager.go#L316-L329.

Кстати, создать вот такой Cleanup метод, который раз и удалит все базы данных, было бы очень трудно в более "кустарных" условиях, так как нужно держать в голове thread-safe способ keep track of этих баз данных. Надеюсь, я объяснил понятно.

Если же вам интересны абстракции в целом, то я сейчас планирую делать разбивку библиотеки, чтобы вынести pq и pgx драйверы из нее... было ли бы вам интересно обсудить эти абстракции в личных сообщениях? Мне важно мнение community.

С уважением,
Андрей

xcono Sep 17 at 08:29

Также можно взглянуть на https://github.com/peterldowns/pgtestdb - проекты очень похожи.

andrei-polukhin Sep 17 at 13:03

Спасибо за комментарий. Соглашусь с вами и, если честно, я узнал об этом проекте уже из коммьюнити на Reddit :) Я посмотрел эту библиотеку и нашел ее очень хорошей. В то же время, два проекта имеют слегка разный фокус и я скопирую вам, что написал на Reddit'е на английском. Дайте знать, если русский вам будет удобнее английского.

To the differences: pgtestdb allows the user to call the New function and not worry about creating or cleaning up the test database — an out-of-the-box solution. Both libraries support pq and pgx; perhaps pdbtemplate allows making it more explicit via the defined NewStandardConnectionProvider and NewPgxConnectionProvider. Yet the focus of libraries is different: I've already shared my ideas on the one you've shared, while the most significant benefit of pgdbtemplate is flexibility and control:

Creating a custom connection provider by implementing pgdbtemplate.ConnectionProvider
Controlling the lifecycle of the databases and how they are created & dropped in the tests
Stricter approach to the predefined connectors pq and pgx (both libraries import it, but it is done statically and not via DriverName in pgdbtemplate)
Ability to either use the predefined FileMigrationRunner or NoOpMigrationRunner (present in both, but pgtestdb has support for migration plugins, while pgtestdb does not). You can read more about advanced use cases in this document: https://github.com/andrei-polukhin/pgdbtemplate/blob/main/docs/ADVANCED.md
Clear benchmarks: specified only in pgdbtemplate and not pgtestdb.

I think the ultimate choice is between wanting to import and go (pgtestdb) — and well-defined abstractions to give the end customer as much control and flexibility as possible (pgdbtemplate). This was my conclusion, but I can be biased, as I am the author of pgdbtemplate ;)

What was your take on the differences between the libraries? If you'd like to share some suggestions for the projects, I'd love to hear more.

OlegIct Sep 17 at 18:02

можно ли указать STRATEGY для создания базы?

andrei-polukhin Sep 17 at 18:11

Спасибо за комментарий, это очень технически грамотный вопрос. Нет, указывать STRATEGY для CREATE DATABASE ... TEMPLATE не нужно, и в большинстве случаев это даже невозможно. Эта опция не имеет отношения к механизму шаблонов, описанному в этой статье.

STRATEGY - это опция, которая управляет методом копирования при создании обычной базы данных из другой обычной базы данных (не шаблона). Это не имеет абсолютно никакого отношения к созданию базы данных из шаблона. Попытка добавить STRATEGY к команде с TEMPLATE вызовет ошибку, так как эти два пункта синтаксически взаимоисключающие. Postgres сам оптимизирует все нужное при создании БД из template'а и дополнительный параметр указывать не нужно.

С уважением,
Андрей

OlegIct Sep 18 at 06:29

попытка добавить не вызывает ошибки:

postgres=# create database db1 strategy file_copy template template1;
CREATE DATABASE

Вероятно, вы использовали GPT, а он пишет ложь, не стоит его использовать.

Свойство "шаблон" в PostgreSQL даёт только то, что без снятия свойства нельзя удалить базу.

Вопрос был в том, что вместо команд SQL для создания базы используются программные вызовы и есть ли в программных вызовах STRATEGY. Я столкнулся с тем, что в pgx нет возможности передать PGOPTIONS.

По скорости, думаю, то же самое - не может программный вызов быть быстрее команды SQL. Основное что влияет на скорость создания баз это её размер и strategy.

IvanG Sep 19 at 06:45

Спасибо за вклад в развитие авто тестов, но надеюсь никто не действует сейчас как вы описали - создать базу с нуля и накатывать миграции для каждого рана теста.

У себя на проектах уже лет 10 использую создание бд/бэкапирование и разворачивание бэкапа на каждый ран (придумал не я, еще зеленым увидел), все это мс скл, может уже тоже какие нить темплейты заехали, но старого коня не поменяли ещё ))

andrei-polukhin Sep 19 at 07:19

Спасибо за конструктивный и добрый комментарий :) Мне интересно, как сейчас делаются такие вещи в разных компаниях — были бы вы открыты рассказать, какими библиотеками/инструментами пользуетесь?