Comments 9
Работает ли firebird с sqlalchemy в асинхронном режиме?
Добрый день, на текущий момент полноценной реализации пока нет. Существуют развивающиеся проекты, например: https://github.com/pycasbin/async-sqlalchemy-adapter, но полноценного диалекта для питона для свежих версий firebird пока не написано
На данный момент для firebird существует только асинхронный драйвер (https://github.com/nakagami/pyfirebirdsql), однако диалекта для sqlalchemy, поддерживающего его, нету
Только в Postgres Pro Enterprise (даже не Standard!) реализована полноценная поддержка автономных транзакций с выполнением автономной транзакции внутри того же серверного процесса
для точности: в Tantor Postgres и EnterpriseDB есть автономные транзакции. В ванильную версию патч предложен но в том что он не принят виноват... Firebird :)) который смутил Павла Стехуле и он хочет видеть синтаксис использования автономных трнзакций как в Firebird. Синтаксис как в Oracle Database (использует Tantor Postgres и EnterpriseDB) не нравится. В переписке можно поискать обсуждение по слову "firebird". Используя предложенный в обсуждении патч можно добавить автономные транзакции самостоятельно в ванильный PostgreSQL.
Именно поэтому во ВСЕХ коммерческих версиях PostgreSQL сейчас реализован 64-битный счетчик транзакций.
Наиболее известной и успешной является реализация от компании Postgres Professional, которые первыми в мире предложили решение.
Есть 4 причины, по которым это решение не только до сих пор отсутствует в ванильной версии
Рефакторинг большого объема кода - весь остальной код PostgreSQL ожидает, что в счетчике будет 32-битное число
В каждой версии строчки есть заголовок. Если счетчик будет 64 битным, то будет слишком много служебной информации на каждую версию строки.
Внесение подобного изменения потребует переделки множества расширений PostgreSQL, которые должны понимать, что номер транзакции теперь 64-битный
"Инертность" сообщества. Решение от Postgres Professional комьюнити отказались принимать из-за размера и сложности. Текущий статус загадочен… "Returned with feedback".
для точности: во всех коммерческих версиях патч Короткова. :) Причины непринятия немного другие. Размер заголовка строки не меняется, старшие 32 бита хранятся в конце блока. Расширения не причем, инертности у целого сообщества нет. Патч большой, сам Коротков указал проблемы патча, без устранения которых не рекомендует его принимать. Например, патч не рассчитан на 32-битные системы, а сообщество не хочет отказываться от их поддержки. В целом, предлагают разбить патч на части и принимать по частям.
Добрый день!
Статья замечательная! Спасибо!
Откройте пожалуйста секрет, почему понадобился переход с продвинутого Firebird на ванильный сервер?
Если я правильно понял вопрос:
Здесь речь именно про "ванильный Firebird". А "продвинутые Firebird" - это HQbird и RedDatabase, которые в статье не упоминаются. И у которых совсем другие "свои фишки", про которые в статье также не упоминается (и даже не имеются в виду).
То, что упоминается в статье, одинаково и у ванильного Firebird, и у продвинутых HQbird и RedDatabase.
А "почему понадобился переход..." - про это в самом начале первой части статьи.
Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 2