使用其他管理命令¶

大多數其他與資料庫互動的 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

最後，在設定檔案中，我們新增以下內容（將 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 和第三方應用程式，請使用相同的方法。