Спасибо за конструктивный и добрый комментарий :) Мне интересно, как сейчас делаются такие вещи в разных компаниях — были бы вы открыты рассказать, какими библиотеками/инструментами пользуетесь?
Спасибо за комментарий, это очень технически грамотный вопрос. Нет, указывать STRATEGY для CREATE DATABASE ... TEMPLATE не нужно, и в большинстве случаев это даже невозможно. Эта опция не имеет отношения к механизму шаблонов, описанному в этой статье.
STRATEGY - это опция, которая управляет методом копирования при создании обычной базы данных из другой обычной базы данных (не шаблона). Это не имеет абсолютно никакого отношения к созданию базы данных из шаблона. Попытка добавить STRATEGY к команде с TEMPLATE вызовет ошибку, так как эти два пункта синтаксически взаимоисключающие. Postgres сам оптимизирует все нужное при создании БД из template'а и дополнительный параметр указывать не нужно.
Прочитал статью и ценю честность автора, равно как и смелость вводить процессы и делать правильные (или "правильные") вещи в компании. Лейтмотив же стар, как мир, — дорога ложка к обеду. Вы хотели вводить инструменты в компанию, которая изначально рассматривала их диковинными. Мы намного более инертны, чем хотим себе признаваться, отсюда такие, как Зиночка, являются более популярными, ибо они "свои среди своих" :)
Желаю вам найти коллектив, где не будут открыто предлагать лгать, а сразу будут процессы, которые вам не надо будет ставить. Дело — не в роли тех-лида, а в среде, где вы свои лидерские навыки применили.
Спасибо за комментарий. Соглашусь с вами и, если честно, я узнал об этом проекте уже из коммьюнити на 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.
Спасибо за комментарий. Я полагаю, такой вопрос можно поставить ко всем абстракциям / декомпозициям. Разумеется, можно делать все это мануально, однако библиотека делает это безопасно с точки зрения асинхронного программирования, дает четкий интерфейс абстракций (что делать за чем), а также имеет четкие benchmark'и.
Кстати, создать вот такой Cleanup метод, который раз и удалит все базы данных, было бы очень трудно в более "кустарных" условиях, так как нужно держать в голове thread-safe способ keep track of этих баз данных. Надеюсь, я объяснил понятно.
Если же вам интересны абстракции в целом, то я сейчас планирую делать разбивку библиотеки, чтобы вынести pq и pgx драйверы из нее... было ли бы вам интересно обсудить эти абстракции в личных сообщениях? Мне важно мнение community.
Спасибо за статью! Нашел ее годной и увидел, как работает Claude "под капотом". Посоветуешь еще что-то прочитать похожее про их фичи? Хочу использовать их ИИ на полную катушку ;)
Спасибо за конструктивный и добрый комментарий :) Мне интересно, как сейчас делаются такие вещи в разных компаниях — были бы вы открыты рассказать, какими библиотеками/инструментами пользуетесь?
Спасибо за комментарий, это очень технически грамотный вопрос. Нет, указывать
STRATEGYдляCREATE DATABASE ... TEMPLATEне нужно, и в большинстве случаев это даже невозможно. Эта опция не имеет отношения к механизму шаблонов, описанному в этой статье.STRATEGY- это опция, которая управляет методом копирования при создании обычной базы данных из другой обычной базы данных (не шаблона). Это не имеет абсолютно никакого отношения к созданию базы данных из шаблона. Попытка добавитьSTRATEGYк команде сTEMPLATEвызовет ошибку, так как эти два пункта синтаксически взаимоисключающие. Postgres сам оптимизирует все нужное при создании БД из template'а и дополнительный параметр указывать не нужно.С уважением,
Андрей
Прочитал статью и ценю честность автора, равно как и смелость вводить процессы и делать правильные (или "правильные") вещи в компании. Лейтмотив же стар, как мир, — дорога ложка к обеду. Вы хотели вводить инструменты в компанию, которая изначально рассматривала их диковинными. Мы намного более инертны, чем хотим себе признаваться, отсюда такие, как Зиночка, являются более популярными, ибо они "свои среди своих" :)
Желаю вам найти коллектив, где не будут открыто предлагать лгать, а сразу будут процессы, которые вам не надо будет ставить. Дело — не в роли тех-лида, а в среде, где вы свои лидерские навыки применили.
Спасибо за комментарий. Соглашусь с вами и, если честно, я узнал об этом проекте уже из коммьюнити на Reddit :) Я посмотрел эту библиотеку и нашел ее очень хорошей. В то же время, два проекта имеют слегка разный фокус и я скопирую вам, что написал на Reddit'е на английском. Дайте знать, если русский вам будет удобнее английского.
To the differences:
pgtestdballows the user to call theNewfunction and not worry about creating or cleaning up the test database — an out-of-the-box solution. Both libraries supportpqandpgx; perhapspdbtemplateallows making it more explicit via the definedNewStandardConnectionProviderandNewPgxConnectionProvider. Yet the focus of libraries is different: I've already shared my ideas on the one you've shared, while the most significant benefit ofpgdbtemplateis 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.
Спасибо за комментарий. Я полагаю, такой вопрос можно поставить ко всем абстракциям / декомпозициям. Разумеется, можно делать все это мануально, однако библиотека делает это безопасно с точки зрения асинхронного программирования, дает четкий интерфейс абстракций (что делать за чем), а также имеет четкие 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.
С уважением,
Андрей
Пиши телегу :) не нашел у тебя в профиле.
Спасибо за статью! Нашел ее годной и увидел, как работает Claude "под капотом". Посоветуешь еще что-то прочитать похожее про их фичи? Хочу использовать их ИИ на полную катушку ;)