Базы данных

Использование других команд управления

Большинство других django-admin команд, взаимодействующих с базой данных, работают так же, как migrate — они всегда работают с одной базой данных за раз, используя --database для управления используемой базой данных.

Исключением из этого правила является команда makemigrations. Она проверяет историю миграций в базах данных, чтобы поймать проблемы с существующими файлами миграций (которые могут быть вызваны их редактированием), прежде чем создавать новые миграции. По умолчанию она проверяет только базу данных default, но она обращается к методу allow_migrate() маршрутизаторов, если они установлены.

Маршрутизаторы баз данных

Маршрутизатор базы данных — это класс, который предоставляет до четырёх методов:

db_for_read(model, **hints)

Предложить базу данных, которая должна использоваться для операций чтения для объектов типа model.

Если операция базы данных может предоставить дополнительную информацию, которая может помочь в выборе базы данных, она будет предоставлена в словаре hints. Сведения о допустимых подсказках приведены ниже.

Возвращает None, если нет предложения.

db_for_write(model, **hints)

Предложить базу данных, которая должна использоваться для записи объектов типа Модель.

Если операция базы данных может предоставить дополнительную информацию, которая может помочь в выборе базы данных, она будет предоставлена в словаре hints. Сведения о допустимых подсказках приведены ниже.

Возвращает None, если нет предложения.

allow_relation(obj1, obj2, **hints)

Возвращает True, если отношение между obj1 и obj2 должно быть разрешено, False, если отношение должно быть предотвращено, или None, если у маршрутизатора нет мнения. Это чисто операция проверки, используемая операциями внешнего ключа и многие ко многим для определения, должно ли быть разрешено отношение между двумя объектами.

Если ни один маршрутизатор не имеет мнения (то есть все маршрутизаторы возвращают None), разрешены только отношения внутри одной базы данных.

allow_migrate(db, app_label, model_name=None, **hints)

Определить, разрешено ли выполнять операцию миграции в базе данных с псевдонимом db. Возвращает True, если операция должна выполняться, False, если она не должна выполняться, или None, если у маршрутизатора нет мнения.

Позиционный аргумент app_label — это метка приложения, которое мигрируется.

model_name устанавливается большинством операций миграции в значение model._meta.model_name (нижнего регистра модели __name__) мигрируемой модели. Его значение равно None для операций RunPython и RunSQL, если они не предоставят его с помощью подсказок.

hints используются некоторыми операциями для передачи дополнительной информации маршрутизатору.

Когда model_name установлено, hints обычно содержит класс модели по ключу 'model'. Обратите внимание, что это может быть историческая модель, и поэтому не будет иметь никаких пользовательских атрибутов, методов или менеджеров. Вы должны полагаться только на _meta.

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

makemigrations всегда создаёт миграции для изменений модели, но если allow_migrate() возвращает False, любые операции миграции для model_name будут проигнорированы при запуске migrate в базе данных db. Изменение поведения allow_migrate() для моделей, у которых уже есть миграции, может привести к нарушению внешних ключей, дополнительных таблиц или отсутствующих таблиц. Когда makemigrations проверяет историю миграций, он пропускает базы данных, где ни одно приложение не может мигрировать.

Маршрутизатор не обязан предоставлять все эти методы — он может опустить один или несколько из них. Если один из методов пропущен, Django пропустит этот маршрутизатор при выполнении соответствующей проверки.

Использование маршрутизаторов

Маршрутизаторы баз данных устанавливаются с помощью параметра DATABASE_ROUTERS. Этот параметр определяет список имён классов, каждый из которых задаёт маршрутизатор, который должен использоваться базовым маршрутизатором (django.db.router).

Базовый маршрутизатор используется операциями базы данных Django для распределения использования баз данных. Всякий раз, когда запрос нуждается в том, чтобы узнать, какую базу данных использовать, он вызывает базовый маршрутизатор, предоставляя модель и подсказку (если она доступна). Базовый маршрутизатор пытается использовать каждый класс маршрутизатора по очереди, пока один не вернёт предложение по базе данных. Если ни один маршрутизатор не возвращает предложения, базовый маршрутизатор пытается использовать текущее instance._state.db подсказки экземпляра. Если подсказка экземпляра не была предоставлена или instance._state.db имеет значение None, базовый маршрутизатор распределит базу данных default.

Пример

Итак, что это значит на практике? Давайте рассмотрим другую примерную конфигурацию. В ней будет несколько баз данных: одна для приложения auth и все остальные приложения, использующие настройку мастер/раб с двумя читаемыми репликами. Вот настройки, определяющие эти базы данных:

DATABASES = {
    "default": {},
    "auth_db": {
        "NAME": "auth_db_name",
        "ENGINE": "django.db.backends.mysql",
        "USER": "mysql_user",
        "PASSWORD": "swordfish",
    },
    "primary": {
        "NAME": "primary_name",
        "ENGINE": "django.db.backends.mysql",
        "USER": "mysql_user",
        "PASSWORD": "spam",
    },
    "replica1": {
        "NAME": "replica1_name",
        "ENGINE": "django.db.backends.mysql",
        "USER": "mysql_user",
        "PASSWORD": "eggs",
    },
    "replica2": {
        "NAME": "replica2_name",
        "ENGINE": "django.db.backends.mysql",
        "USER": "mysql_user",
        "PASSWORD": "bacon",
    },
}

Теперь нам нужно обработать маршрутизацию. Сначала нам нужен маршрутизатор, который знает, что нужно отправлять запросы для приложений auth и contenttypes в auth_db (модели auth связаны с ContentType, поэтому они должны храниться в одной базе данных):

class AuthRouter:
    """
    A router to control all database operations on models in the
    auth and contenttypes applications.
    """

    route_app_labels = {"auth", "contenttypes"}

    def db_for_read(self, model, **hints):
        """
        Attempts to read auth and contenttypes models go to auth_db.
        """
        if model._meta.app_label in self.route_app_labels:
            return "auth_db"
        return None

    def db_for_write(self, model, **hints):
        """
        Attempts to write auth and contenttypes models go to auth_db.
        """
        if model._meta.app_label in self.route_app_labels:
            return "auth_db"
        return None

    def allow_relation(self, obj1, obj2, **hints):
        """
        Allow relations if a model in the auth or contenttypes apps is
        involved.
        """
        if (
            obj1._meta.app_label in self.route_app_labels
            or obj2._meta.app_label in self.route_app_labels
        ):
            return True
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        Make sure the auth and contenttypes apps only appear in the
        'auth_db' database.
        """
        if app_label in self.route_app_labels:
            return db == "auth_db"
        return None

И нам также нужен маршрутизатор, который отправляет все остальные приложения в конфигурацию мастер/раб и случайным образом выбирает реплику для чтения:

import random


class PrimaryReplicaRouter:
    def db_for_read(self, model, **hints):
        """
        Reads go to a randomly-chosen replica.
        """
        return random.choice(["replica1", "replica2"])

    def db_for_write(self, model, **hints):
        """
        Writes always go to primary.
        """
        return "primary"

    def allow_relation(self, obj1, obj2, **hints):
        """
        Relations between objects are allowed if both objects are
        in the primary/replica pool.
        """
        db_set = {"primary", "replica1", "replica2"}
        if obj1._state.db in db_set and obj2._state.db in db_set:
            return True
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        All non-auth models end up in this pool.
        """
        return True

Наконец, в файле настроек мы добавим следующее (заменив path.to. фактическим путём к модулю/модулям, где определены маршрутизаторы):

DATABASE_ROUTERS = ["path.to.AuthRouter", "path.to.PrimaryReplicaRouter"]

Порядок обработки маршрутизаторов важен. Маршрутизаторы будут запрошены в порядке, в котором они указаны в параметре DATABASE_ROUTERS. В этом примере, AuthRouter обрабатывается до PrimaryReplicaRouter, и в результате решения, касающиеся моделей в auth, обрабатываются до принятия любого другого решения. Если в параметре DATABASE_ROUTERS маршрутизаторы были указаны в обратном порядке, PrimaryReplicaRouter.allow_migrate() обрабатывался бы первым. Специфичность реализации PrimaryReplicaRouter означала бы, что все модели были бы доступны во всех базах данных.

После установки этой настройки и миграции всех баз данных, как указано в Синхронизации баз данных, давайте запустим код Django:

>>> # This retrieval will be performed on the 'auth_db' database
>>> fred = User.objects.get(username="fred")
>>> fred.first_name = "Frederick"

>>> # This save will also be directed to 'auth_db'
>>> fred.save()

>>> # These retrieval will be randomly allocated to a replica database
>>> dna = Person.objects.get(name="Douglas Adams")

>>> # A new object has no database allocation when created
>>> mh = Book(title="Mostly Harmless")

>>> # This assignment will consult the router, and set mh onto
>>> # the same database as the author object
>>> mh.author = dna

>>> # This save will force the 'mh' instance onto the primary database...
>>> mh.save()

>>> # ... but if we re-retrieve the object, it will come back on a replica
>>> mh = Book.objects.get(title="Mostly Harmless")

В этом примере был определён маршрутизатор для обработки взаимодействия с моделями из приложения auth, и другие маршрутизаторы для обработки взаимодействия со всеми другими приложениями. Если вы оставили базу данных default пустой и не хотите определять маршрутизатор по умолчанию для обработки всех приложений, которые не указаны иначе, ваши маршрутизаторы должны обрабатывать имена всех приложений в INSTALLED_APPS, прежде чем вы начнете миграцию. См. Поведение приложений contrib для получения информации о приложениях contrib, которые должны быть вместе в одной базе данных.

Ручное выбор базы данных для QuerySet

Вы можете выбрать базу данных для QuerySet в любой момент в QuerySet «цепочке». Вызовите using() для QuerySet, чтобы получить другой QuerySet, использующий указанную базу данных.

using() принимает один аргумент: псевдоним базы данных, на которой вы хотите выполнить запрос. Например:

>>> # This will run on the 'default' database.
>>> Author.objects.all()

>>> # So will this.
>>> Author.objects.using("default")

>>> # This will run on the 'other' database.
>>> Author.objects.using("other")

Выбор базы данных для save()

Используйте ключевое слово using, чтобы Model.save() указать, в какую базу данных должны быть сохранены данные.

Например, чтобы сохранить объект в базу данных legacy_users, используйте это:

>>> my_object.save(using="legacy_users")

Если вы не укажете using, метод save() сохранит данные в базу данных по умолчанию, назначенную маршрутизаторами.

>>> p = Person(name="Fred")
>>> p.save(using="first")  # (statement 1)
>>> p.save(using="second")  # (statement 2)

>>> p = Person(name="Fred")
>>> p.save(using="first")
>>> p.pk = None  # Clear the primary key.
>>> p.save(using="second")  # Write a completely new object.

>>> p = Person(name="Fred")
>>> p.save(using="first")
>>> p.save(using="second", force_insert=True)

Выбор базы данных для удаления

По умолчанию вызов удаления существующего объекта будет выполнен в той же базе данных, что и использовалась для извлечения объекта в первую очередь:

>>> u = User.objects.using("legacy_users").get(username="fred")
>>> u.delete()  # will delete from the `legacy_users` database

Чтобы указать базу данных, из которой будет удалена модель, передайте ключевой аргумент using в метод Model.delete(). Этот аргумент работает так же, как и ключевой аргумент using для save().

Например, если вы мигрируете пользователя из базы данных legacy_users в базу данных new_users, вы можете использовать следующие команды:

>>> user_obj.save(using="new_users")
>>> user_obj.delete(using="legacy_users")

Использование менеджеров с несколькими базами данных

Используйте метод db_manager() для менеджеров, чтобы предоставить менеджерам доступ к базе данных, отличной от базы данных по умолчанию.

Например, предположим, что у вас есть пользовательский метод менеджера, который взаимодействует с базой данных — User.objects.create_user(). Поскольку create_user() — это метод менеджера, а не метод QuerySet, вы не можете сделать User.objects.using('new_users').create_user(). (Метод create_user() доступен только для User.objects, менеджера, а не для объектов QuerySet, полученных из менеджера.) Решение — использовать db_manager(), как показано ниже:

User.objects.db_manager("new_users").create_user(...)

db_manager() возвращает копию менеджера, связанного с указанной вами базой данных.

class MyManager(models.Manager):
    def get_queryset(self):
        qs = CustomQuerySet(self.model)
        if self._db is not None:
            qs = qs.using(self._db)
        return qs

Взаимосвязи между базами данных

В Django в настоящее время нет поддержки внешних ключей или взаимосвязей «многие ко многим», охватывающих несколько баз данных. Если вы использовали маршрутизатор для разделения моделей по разным базам данных, любые внешние ключи и взаимосвязи «многие ко многим», определенные этими моделями, должны быть внутренними для одной базы данных.

Это связано с целостностью ссылок. Для поддержания связи между двумя объектами Django необходимо знать, что первичный ключ связанного объекта действителен. Если первичный ключ хранится в отдельной базе данных, то легко оценить действительность первичного ключа невозможно.

Если вы используете Postgres, SQLite, Oracle или MySQL с InnoDB, это обеспечивается на уровне целостности базы данных — ограничения на уровне базы данных для ключей предотвращают создание связей, которые нельзя проверить.

Однако, если вы используете MySQL с таблицами MyISAM, принудительная целостность ссылок не поддерживается; в результате вы можете «подделать» внешние ключи между базами данных. Тем не менее, такая конфигурация не поддерживается официально Django.

Поведение приложений contrib

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

• каждый из contenttypes.ContentType, sessions.Session и sites.Site может храниться в любой базе данных, при условии подходящего маршрутизатора.
• auth модели — User, Group и Permission — связаны друг с другом и связаны с ContentType, поэтому они должны храниться в той же базе данных, что и ContentType.
• admin зависит от auth, поэтому его модели должны храниться в той же базе данных, что и auth.
• flatpages и redirects зависят от sites, поэтому их модели должны храниться в той же базе данных, что и sites.

Кроме того, некоторые объекты автоматически создаются сразу после того, как migrate создаёт таблицу для их хранения в базе данных:

• по умолчанию Site,
• ContentType для каждой модели (включая те, которые не хранятся в этой базе данных),
• Permission для каждой модели (включая те, которые не хранятся в этой базе данных).

В распространённых сценариях с несколькими базами данных нет смысла иметь эти объекты в более чем одной базе данных. К распространённым сценариям относятся главная/резервная и подключение к внешним базам данных. Поэтому рекомендуется написать маршрутизатор базы данных маршрутизатор базы данных, который позволяет синхронизировать эти три модели только с одной базой данных. Используйте тот же подход для приложений contrib и сторонних приложений, которым не нужны их таблицы в нескольких базах данных.