Как реализовать одновременное подключение модели peewee к нескольким БД?

Question

[Семён Приходько]

Читая справку по peewee, был поражён способом задания подключения к БД: через встроенный класс метаданных внутри базовой модели. Т.е. в каждый момент времени модель может иметь только ОДНО подключение к базе.

Теперь представим вполне реальный сценарий. Есть приложение in production, использующее модуль с моделью данных. Я хочу прогнать тесты с новым функционалом, использующим эту же модель (база, разумеется, другая - тестовая). Получается, что это принципиально невозможно сделать, поскольку наш модуль может работать только с одним подключением. Я правильно понимаю? Есть ли красивый и простой способ обойти это ограничение?

Answer 1

[LocNar]

Proxy — peewee API#Proxy

В продолжение темы, если грязно эмулировать работу django:

# -*- coding: utf-8 -*-

import peewee

db = peewee.Proxy()
first = peewee.SqliteDatabase('first.db')
second = peewee.SqliteDatabase('second.db')


class Test(peewee.Model):
    name = peewee.CharField()

    class Meta:
        database = db
        db_table = 'test'

    @classmethod
    def using(cls, db):
        cls._meta.database.initialize(db)
        return cls

db.initialize(first)
Test.create_table(fail_silently=True)
db.initialize(second)
Test.create_table(fail_silently=True)

Test.using(first).create(name='Test1')  # Переключились на first
Test.create(name='Test2')  # Используется ранее переключенная база first
Test.using(second).create(name='Test3')  # Переключились на secong
Test.create(name='Test4')  # Пишется в second
Test.using(first).create(name='Test5')
print ','.join([x.name for x in Test.using(first).select()])
# Test1,Test2,Test5
print ','.join([x.name for x in Test.using(second).select()])
# Test3,Test4

Вообще peewee активно развивается и постоянно вводит новые фичи, так что можно написать ему на github, вполне возможно, что в следующей версии грязные хаки не понадобятся.

Но тем не менее до сих пор сомневаюсь в целесообразности подобного поведения в целом.

Ещё возможно алиасы моделей могут иметь свои подключения, но читать сурс или проверять лень.

Comments

[Семён Приходько]

Proxy не решает данной задачи, он лишь позволяет переключаться с одной базы на другую.

[LocNar]

Ничего не мешает перед тестами инициализировать Proxy другой базой, например явно перед вызовом тестов, в setUpClass.

[Семён Приходько]

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

[LocNar]

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

Соединения можно открыть раньше, а затем лишь переключать по ссылкам, в django .using() делает примерно тоже самое.

[LocNar]

Обновил текст основного ответа, вы вроде как именно этого хотите.

[Семён Приходько]

Спасибо за развёрнутый ответ. Всё-таки, такой дизайн мне кажется странным. Почему бы не отвязать модель от базы данных? Если накладно хранить в каждом объекте ссылку на подключение, то можно динамически создавать подкласс при создании нового подключения. Например, пусть у нас есть класс пользователя:

class User(Model):
username = CharField()

class Meta:
db = SqliteDatabase(DATABASE1)

Тогда делаем:

db = SqliteDatabase(DATABASE2)

# при первом вызове динамически создаётся класс,
# производный от User, а create возвращает его новый экземпляр
user = User.create(db=db, username='user')

Т.е. поскольку большинство задач сводится к одной базе, то работает база по умолчанию (если задана). Если же нужно работать со второй базой (вполне реальный сценарий, например, нужно перегнать одну базу в другую с некоторыми преобразованиями, напр. фильтрацией) - то можно задать опциональный параметр db.

[Семён Приходько]

Плохо, что в комментах нету ни поддержки кода, ни отступов

[LocNar]

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

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

Но, как я уже указал выше, можно написать автору библиотеки, он её активно развивает.
Возможно будет изкоробочное куда менее костыльное решение, но, надеюсь, он все же не заставит городить излишние сущности вроде менеджеров django для тех, у кого модель строго привязана к базе.