Что такое хороший способ организовать ваши модели, соединения, если вы хотите использовать SQLAlchemy для подключения нескольких баз данных к различным приложениям?

Задний план:

Это та ситуация, с которой я столкнулся, и до сих пор мое нынешнее решение кажется довольно неуклюжим. Я хочу улучшить его. Прямо сейчас:

Я устанавливаю подключения к каждой базе данных в основной функции приложения Pyramid:

def main(global_config, **settings): a_engine = engine_from_config(settings, 'A.') b_engine = engine_from_config(settings, 'B.') ASession.configure(bind=a_engine) BSession.configure(bind=b_engine)

«ASession» и «BSession» – это просто глобально определенный scoped_session в / models / init .py.

 ASession = scoped_session(sessionmaker(extension=ZopeTransactionExtension()))

Я так определяю базовый класс модели. Например:

 ABase = declarative_base() class user(ABase): id = Column(Integer, primary_key=True) name = Column(String)

Это как-то уже не очень чисто. Но теперь, когда предполагается, что эта модель будет доступна из другого приложения, мне также необходимо определить двигатель и соединение в этом приложении. Это кажется чрезвычайно избыточным.

Проблема:

Предположим, что есть две разные базы данных:

A и B

Также предположите, что вы хотите, чтобы A и B были доступны из двух разных приложений (например: приложение Pyramid, приложение Bokeh Server App, которое использует Tornado) с использованием той же модели.

Короче говоря, как можно было бы создать лучшие объекты / модели / классы / функции шаблонов для создания чистого не избыточного кода в Python3?

Первоначальная мысль после вопроса:

Думая об этом немного больше, я думаю, что каждая модель должна быть как-то «автономной». Модель должна принести с собой методы для запуска соединений. Другими словами, инициация соединений db должна быть отделена от самого веб-приложения.

И это должно быть сделано в виде экземпляра. Так что несколько приложений могут использовать одни и те же модели. Каждое приложение будет иметь собственное сеансовое соединение с одной из БД.

Как бы это сложилось в сообществе? Пятница после обеда не может найти ответы на эти вопросы для меня, по крайней мере.

One Solution collect form web for “Что такое хороший способ организовать ваши модели, соединения, если вы хотите использовать SQLAlchemy для подключения нескольких баз данных к различным приложениям?”

Я сделал это. Моя рекомендация ниже – как мне нравится это делать, но это не единственный способ. Я бы расколол сессионные сеансы и диспетчер транзакций и создал явные объекты управления сеансом, с обратными вызовами жизненного цикла запроса обработка, закрытие, фиксация или сворачивание ваших сеансов. Занятые в основном сеансы – это способ имитации глобального, получая один и тот же элемент для этого потока выполнения. Другой способ сделать это в Pyramid – это прикрепить вещи к реестру и запросу, потому что у вас есть все это везде . Вы присоединяете общие компоненты к реестру (ZCA) и к объектам запроса для запроса.

Когда у вас несколько сеансов, мне было гораздо легче рассуждать о них и отслеживать их, если они обрабатываются компонентами, которые завершают все для этого движка. Поэтому для такого случая, который вы описываете, я создал два разных компонента движка базы данных, которые создаются при запуске, прикрепляются к реестру и имеют метод для получения нового сеанса. Если вы правильно создадите эти компоненты, они должны использоваться в любом приложении, будь то Pyramid, Tornado или ваш тестовый скрипт. Вы просто убедитесь, что у него есть конструктор с разумным способом передачи в настройках для настройки движка, будь то настройки dict или kwargs. Затем я делаю свои модели данных в своих пакетах python, и легко подключить любое приложение в семействе, импортируя модель, создать экземпляр компонентов двигателя и перейти в город. Обратите внимание: если вам нравится использовать реестр ZCA (и мне это нравится, это фантастическая система DI), нет ничего, что помешало бы вам использовать его в приложениях без пирамиды, вы просто настроили его вручную на своем стартовом компьютере.

В Pyramid специально я создаю пользовательский класс Request и использую декоратор reify, чтобы разрешить другим пирамидным кодом получать сеанс (ы) для этого запроса. Класс запроса имеет завершающие обратные вызовы, связанные с закрытием сеансов, а также откаты или коммиты. Существует немного больше шаблонов, но для меня это чище, потому что я могу очень легко отслеживать, где и когда в коде и времени происходит управление сеансом. Это также хороший способ тестирования.

Тем не менее, есть много умных людей в землях SQLAlchemy / Pyramid, которые клянутся сессиями с привязкой и менеджером транзакций, поэтому существуют и другие действующие подходы. Надеюсь, это поможет.