Комментарии 9
Я что то так и не понял чем это решение отличается от вызова create database from template и drop database в конце?
Спасибо за комментарий. Я полагаю, такой вопрос можно поставить ко всем абстракциям / декомпозициям. Разумеется, можно делать все это мануально, однако библиотека делает это безопасно с точки зрения асинхронного программирования, дает четкий интерфейс абстракций (что делать за чем), а также имеет четкие 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.
С уважением,
Андрей
Также можно взглянуть на https://github.com/peterldowns/pgtestdb - проекты очень похожи.
Спасибо за комментарий. Соглашусь с вами и, если честно, я узнал об этом проекте уже из коммьюнити на 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.ConnectionProviderControlling 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
DriverNamein pgdbtemplate)Ability to either use the predefined
FileMigrationRunnerorNoOpMigrationRunner(present in both, butpgtestdbhas 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.mdClear benchmarks: specified only in
pgdbtemplateand notpgtestdb.
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.
можно ли указать STRATEGY для создания базы?
Спасибо за комментарий, это очень технически грамотный вопрос. Нет, указывать STRATEGY для CREATE DATABASE ... TEMPLATE не нужно, и в большинстве случаев это даже невозможно. Эта опция не имеет отношения к механизму шаблонов, описанному в этой статье.
STRATEGY - это опция, которая управляет методом копирования при создании обычной базы данных из другой обычной базы данных (не шаблона). Это не имеет абсолютно никакого отношения к созданию базы данных из шаблона. Попытка добавить STRATEGY к команде с TEMPLATE вызовет ошибку, так как эти два пункта синтаксически взаимоисключающие. Postgres сам оптимизирует все нужное при создании БД из template'а и дополнительный параметр указывать не нужно.
С уважением,
Андрей
попытка добавить не вызывает ошибки:
postgres=# create database db1 strategy file_copy template template1;
CREATE DATABASEВероятно, вы использовали GPT, а он пишет ложь, не стоит его использовать.
Свойство "шаблон" в PostgreSQL даёт только то, что без снятия свойства нельзя удалить базу.
Вопрос был в том, что вместо команд SQL для создания базы используются программные вызовы и есть ли в программных вызовах STRATEGY. Я столкнулся с тем, что в pgx нет возможности передать PGOPTIONS.
По скорости, думаю, то же самое - не может программный вызов быть быстрее команды SQL. Основное что влияет на скорость создания баз это её размер и strategy.
Спасибо за вклад в развитие авто тестов, но надеюсь никто не действует сейчас как вы описали - создать базу с нуля и накатывать миграции для каждого рана теста.
У себя на проектах уже лет 10 использую создание бд/бэкапирование и разворачивание бэкапа на каждый ран (придумал не я, еще зеленым увидел), все это мс скл, может уже тоже какие нить темплейты заехали, но старого коня не поменяли ещё ))

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