使用其他管理命令¶

大多数其他与数据库交互的 django-admin 命令的工作方式与 migrate 相同——它们一次只在一个数据库上操作，使用 --database 来控制使用的数据库。

此规则的一个例外是 makemigrations 命令。它验证数据库中的迁移历史记录，以便在创建新迁移之前捕获现有迁移文件的问题（这可能是由编辑它们引起的）。默认情况下，它只检查 default 数据库，但如果安装了任何 路由器，它会咨询其 allow_migrate() 方法。

数据库路由器¶

数据库路由器是一个类，它最多提供四种方法

db_for_read(model, **hints)¶

建议应用于类型为 model 的对象的读取操作的数据库。

如果数据库操作能够提供任何可能有助于选择数据库的附加信息，它将提供在 hints 字典中。下面提供了有关有效提示的详细信息。

如果没有建议，则返回 None。

db_for_write(model, **hints)¶

建议应用于 Model 类型对象的写入操作的数据库。

如果数据库操作能够提供任何可能有助于选择数据库的附加信息，它将提供在 hints 字典中。下面提供了有关有效提示的详细信息。

如果没有建议，则返回 None。

allow_relation(obj1, obj2, **hints)¶

如果应允许 obj1 和 obj2 之间的关联，则返回 True；如果应阻止关联，则返回 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__的小写版本），该模型正在迁移。对于RunPython和RunSQL操作，除非它们使用提示提供值，否则其值为None。

hints用于某些操作向路由器传达附加信息。

当设置model_name时，hints通常在键'model'下包含模型类。请注意，它可能是历史模型，因此可能没有任何自定义属性、方法或管理器。你应该只依赖_meta。

此方法也可用于确定给定数据库上模型的可用性。

makemigrations始终为模型更改创建迁移，但如果allow_migrate()返回False，则在db上运行migrate时，model_name的任何迁移操作都将被静默跳过。更改已具有迁移的模型的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

最后，在 settings 文件中，我们添加以下内容（将path.to.替换为定义路由器的模块的实际 Python 路径）

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的数据库。在QuerySet上调用using()以获取另一个使用指定数据库的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()方法。此参数的工作方式与save()的using关键字参数相同。

例如，如果您要将用户从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或带有InnoDB的MySQL，则会在数据库完整性级别强制执行此操作——数据库级别的键约束会阻止创建无法验证的关系。

但是，如果使用的是带有MyISAM表的MySQL，则没有强制执行引用完整性；因此，您可能能够“伪造”跨数据库外键。但是，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 和第三方应用程序，也使用相同的方法。