Denna ämnesguide beskriver Djangos stöd för att interagera med flera databaser. Det mesta av resten av Djangos dokumentation förutsätter att du interagerar med en enda databas. Om du vill interagera med flera databaser måste du vidta några ytterligare åtgärder.
\n\nDet första steget för att använda mer än en databas med Django är att berätta för Django om de databasservrar du kommer att använda. Detta görs med hjälp av inställningen DATABASES. Denna inställning mappar databasalias, som är ett sätt att hänvisa till en specifik databas i hela Django, till en ordbok med inställningar för den specifika anslutningen. Inställningarna i de inre ordböckerna beskrivs i sin helhet i DATABASES-dokumentationen.
Databaser kan ha vilket alias du vill. Aliaset default har dock en speciell betydelse. Django använder databasen med aliaset default när ingen annan databas har valts.
Följande är ett exempel på settings.py snutt som definierar två databaser - en standard PostgreSQL-databas och en MySQL-databas som heter users:
DATABASES = {\n "default": {\n "NAME": "app_data",\n "ENGINE": "django.db.backends.postgresql",\n "USER": "postgres_user",\n "PASSWORD": "s3krit",\n },\n "users": {\n "NAME": "user_data",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "priv4te",\n },\n}\nOm konceptet med en default databas inte är meningsfullt i samband med ditt projekt, måste du vara noga med att alltid ange den databas som du vill använda. Django kräver att en default databaspost definieras, men parameterordlistan kan lämnas tom om den inte kommer att användas. För att göra detta måste du ställa in DATABASE_ROUTERS för alla dina appars modeller, inklusive de i alla contrib- och tredjepartsappar som du använder, så att inga frågor dirigeras till standarddatabasen. Följande är ett exempel på en settings.py snutt som definierar två icke-standarddatabaser, med default posten avsiktligt lämnad tom:
DATABASES = {\n "default": {},\n "users": {\n "NAME": "user_data",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "superS3cret",\n },\n "customers": {\n "NAME": "customer_data",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_cust",\n "PASSWORD": "veryPriv@ate",\n },\n}\nOm du försöker komma åt en databas som du inte har definierat i din DATABASES-inställning, kommer Django att göra ett django.utils.connection.ConnectionDoesNotExist undantag.
Ledningskommandot migrate arbetar med en databas i taget. Som standard används databasen default, men genom att ange alternativet --database kan du be kommandot att synkronisera en annan databas. Så för att synkronisera alla modeller till alla databaser i det första exemplet ovan måste du anropa:
$ ./manage.py migrate\n$ ./manage.py migrate --database=users\nOm du inte vill att alla program ska synkroniseras med en viss databas kan du definiera en databasrouter som implementerar en policy som begränsar tillgängligheten för vissa modeller.
\nOm du, som i det andra exemplet ovan, har lämnat databasen default tom, måste du ange ett databasnamn varje gång du kör migrate. Om du utelämnar databasnamnet kommer du att få ett felmeddelande. För det andra exemplet:
$ ./manage.py migrate --database=users\n$ ./manage.py migrate --database=customers\nDe flesta andra kommandon i django-admin som interagerar med databasen fungerar på samma sätt som migrate` - de fungerar bara på en databas i taget och använder --database för att styra vilken databas som används.
Ett undantag från denna regel är kommandot makemigrations. Det validerar migreringshistoriken i databaserna för att upptäcka problem med de befintliga migreringsfilerna (som kan orsakas av att de redigerats) innan nya migreringar skapas. Som standard kontrolleras endast databasen default, men metoden allow_migrate`() i routers konsulteras om någon sådan finns installerad.
Det enklaste sättet att använda flera databaser är att konfigurera ett routningsschema för databaser. Standarddirigeringsschemat säkerställer att objekt förblir ”klibbiga” till sin ursprungliga databas (dvs. ett objekt som hämtas från databasen foo kommer att sparas i samma databas). Standarddirigeringsschemat säkerställer att om en databas inte anges, går alla frågor tillbaka till standard-databasen.
Du behöver inte göra någonting för att aktivera standardroutningsschemat - det tillhandahålls ”direkt” i alla Django-projekt. Men om du vill implementera mer intressanta beteenden för databasallokering kan du definiera och installera dina egna databasroutrar.
\nEn databasrouter är en klass som tillhandahåller upp till fyra metoder:
\nFöreslå den databas som bör användas för läsoperationer för objekt av typen model.
Om en databasoperation kan tillhandahålla ytterligare information som kan hjälpa till att välja en databas, kommer den att tillhandahållas i ordlistan hints. Detaljer om giltiga hintar finns under.
Returnerar None om det inte finns något förslag.
Föreslå vilken databas som bör användas för skrivningar av objekt av typen Model.
\nOm en databasoperation kan tillhandahålla ytterligare information som kan hjälpa till att välja en databas, kommer den att tillhandahållas i ordlistan hints. Detaljer om giltiga hintar finns under.
Returnerar None om det inte finns något förslag.
Returnerar True om en relation mellan obj1 och obj2 bör tillåtas, False om relationen bör förhindras, eller None om routern inte har någon åsikt. Detta är en ren valideringsoperation som används av foreign key och many to many-operationer för att avgöra om en relation ska tillåtas mellan två objekt.
Om ingen router har en åsikt (d.v.s. alla routrar returnerar None), är endast relationer inom samma databas tillåtna.
Avgör om migreringsoperationen får köras på databasen med aliaset db. Returnerar True om åtgärden ska köras, False om den inte ska köras, eller None om routern inte har någon åsikt.
Det positionella argumentet app_label är etiketten för den applikation som migreras.
model_name sätts av de flesta migreringsoperationer till värdet av model._meta.model_name (den gemena versionen av modellens __name__) för den modell som migreras. Dess värde är None för operationerna RunPython och RunSQL om de inte tillhandahåller det med hjälp av tips.
hints används av vissa operationer för att kommunicera ytterligare information till routern.
När model_name är inställt innehåller hints normalt modellklassen under nyckeln 'model'. Observera att det kan vara en historisk modell, och därmed inte ha några anpassade attribut, metoder eller hanterare. Du bör bara förlita dig på _meta.
Denna metod kan också användas för att avgöra om en modell finns tillgänglig i en viss databas.
\nmakemigrations skapar alltid migreringar för modelländringar, men om allow_migrate() returnerar False, kommer alla migreringsåtgärder för model_name att tyst hoppas över när du kör migrate på db. Att ändra beteendet för allow_migrate() för modeller som redan har migreringar kan resultera i trasiga utländska nycklar, extra tabeller eller tabeller som saknas. När makemigrations verifierar migreringshistoriken hoppar den över databaser där ingen app tillåts migrera.
En router behöver inte tillhandahålla alla dessa metoder - den kan utelämna en eller flera av dem. Om en av metoderna utelämnas kommer Django att hoppa över den routern när den utför den relevanta kontrollen.
\nDe tips som databasroutern tar emot kan användas för att avgöra vilken databas som ska ta emot en viss förfrågan.
\nAt present, the only hint that will be provided is instance, an\nobject instance that is related to the read or write operation that is\nunderway. This might be the instance that is being saved, or it might\nbe an instance that is being added in a many-to-many relation. In some\ncases, no instance hint will be provided at all. The router checks for\nthe existence of an instance hint, and determines if that hint should be\nused to alter routing behavior.
If an instance hint is present, the database from which it was fetched\nis recorded on its instance._state.db.\nRouters will need to first consult that attribute before falling back to any\nfixed alias to match Django’s default behavior of fetching related instances\nfrom the same database.
Databasroutrar installeras med hjälp av inställningen DATABASE_ROUTERS. Den här inställningen definierar en lista med klassnamn som var och en anger en router som ska användas av basroutern (django.db.router).
Basroutern används av Djangos databasoperationer för att fördela databasanvändning. När en fråga behöver veta vilken databas som ska användas, anropar den basroutern och tillhandahåller en modell och en ledtråd (om tillgänglig). Basroutern provar varje routerklass i tur och ordning tills en av dem returnerar ett databasförslag. Om inga routrar returnerar ett förslag försöker basroutern med den aktuella instance._state.db i hint-instansen. Om ingen hint-instans tillhandahölls, eller om instance._state.db är None, kommer basroutern att allokera default-databasen.
Så - vad innebär detta i praktiken? Låt oss överväga en annan exempelkonfiguration. Den här kommer att ha flera databaser: en för auth-applikationen och alla andra appar som använder en primär / replika-installation med två läsrepliker. Här är inställningarna som specificerar dessa databaser:
DATABASES = {\n "default": {},\n "auth_db": {\n "NAME": "auth_db_name",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "swordfish",\n },\n "primary": {\n "NAME": "primary_name",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "spam",\n },\n "replica1": {\n "NAME": "replica1_name",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "eggs",\n },\n "replica2": {\n "NAME": "replica2_name",\n "ENGINE": "django.db.backends.mysql",\n "USER": "mysql_user",\n "PASSWORD": "bacon",\n },\n}\nNu måste vi hantera routning. Först vill vi ha en router som vet att skicka frågor för apparna auth och contenttypes till auth_db (auth modeller är länkade till ContentType, så de måste lagras i samma databas):
class AuthRouter:\n """\n A router to control all database operations on models in the\n auth and contenttypes applications.\n """\n\n route_app_labels = {"auth", "contenttypes"}\n\n def db_for_read(self, model, **hints):\n """\n Attempts to read auth and contenttypes models go to auth_db.\n """\n if model._meta.app_label in self.route_app_labels:\n return "auth_db"\n return None\n\n def db_for_write(self, model, **hints):\n """\n Attempts to write auth and contenttypes models go to auth_db.\n """\n if model._meta.app_label in self.route_app_labels:\n return "auth_db"\n return None\n\n def allow_relation(self, obj1, obj2, **hints):\n """\n Allow relations if a model in the auth or contenttypes apps is\n involved.\n """\n if (\n obj1._meta.app_label in self.route_app_labels\n or obj2._meta.app_label in self.route_app_labels\n ):\n return True\n return None\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n """\n Make sure the auth and contenttypes apps only appear in the\n 'auth_db' database.\n """\n if app_label in self.route_app_labels:\n return db == "auth_db"\n return None\nOch vi vill också ha en router som skickar alla andra appar till konfigurationen primär/replika och slumpmässigt väljer en replika att läsa från:
\nimport random\n\n\nclass PrimaryReplicaRouter:\n def db_for_read(self, model, **hints):\n """\n Reads go to a randomly-chosen replica.\n """\n return random.choice(["replica1", "replica2"])\n\n def db_for_write(self, model, **hints):\n """\n Writes always go to primary.\n """\n return "primary"\n\n def allow_relation(self, obj1, obj2, **hints):\n """\n Relations between objects are allowed if both objects are\n in the primary/replica pool.\n """\n db_set = {"primary", "replica1", "replica2"}\n if obj1._state.db in db_set and obj2._state.db in db_set:\n return True\n return None\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n """\n All non-auth models end up in this pool.\n """\n return True\nSlutligen lägger vi till följande i inställningsfilen (ersätter path.to. med den faktiska Python-sökvägen till den eller de moduler där routrarna definieras):
DATABASE_ROUTERS = ["path.to.AuthRouter", "path.to.PrimaryReplicaRouter"]\nDen ordning i vilken routrarna behandlas är viktig. Routrar kommer att efterfrågas i den ordning de listas i DATABASE_ROUTERS. I det här exemplet bearbetas AuthRouter före PrimaryReplicaRouter, vilket innebär att beslut som rör modellerna i auth bearbetas innan något annat beslut fattas. Om inställningen DATABASE_ROUTERS hade listat de två routrarna i en annan ordning skulle PrimaryReplicaRouter.allow_migrate() bearbetas först. PrimaryReplicaRouter-implementeringens catch-all-karaktär skulle innebära att alla modeller skulle vara tillgängliga i alla databaser.
With this setup installed, and all databases migrated as per\nSynkronisering av dina databaser, let’s run some Django code:
\n>>> # This retrieval will be performed on the 'auth_db' database\n>>> fred = User.objects.get(username="fred")\n>>> fred.first_name = "Frederick"\n\n>>> # This save will also be directed to 'auth_db'\n>>> fred.save()\n\n>>> # These retrieval will be randomly allocated to a replica database\n>>> dna = Person.objects.get(name="Douglas Adams")\n\n>>> # A new object has no database allocation when created\n>>> mh = Book(title="Mostly Harmless")\n\n>>> # This assignment will consult the router, and set mh onto\n>>> # the same database as the author object\n>>> mh.author = dna\n\n>>> # This save will force the 'mh' instance onto the primary database...\n>>> mh.save()\n\n>>> # ... but if we re-retrieve the object, it will come back on a replica\n>>> mh = Book.objects.get(title="Mostly Harmless")\nI det här exemplet definierades en router för att hantera interaktion med modeller från appen auth och andra routrar för att hantera interaktion med alla andra appar. Om du har lämnat din default-databas tom och inte vill definiera en allomfattande databasrouter för att hantera alla appar som inte anges på annat sätt, måste dina routrar hantera namnen på alla appar i INSTALLED_APPS innan du migrerar. Se Beteende hos Contrib-appar för information om contrib-appar som måste vara samlade i en databas.
Django tillhandahåller också ett API som gör att du kan behålla fullständig kontroll över databasanvändningen i din kod. En manuellt angiven databasallokering kommer att prioriteras framför en databas som allokerats av en router.
\nQuerySetLink to this heading#Du kan välja databas för ett QuerySet när som helst i QuerySet ”kedjan” Anropa using() på QuerySet för att få ett annat QuerySet som använder den angivna databasen.
using() tar ett enda argument: aliaset för den databas som du vill köra frågan på. Till exempel:
>>> # This will run on the 'default' database.\n>>> Author.objects.all()\n\n>>> # So will this.\n>>> Author.objects.using("default")\n\n>>> # This will run on the 'other' database.\n>>> Author.objects.using("other")\nsave()Link to this heading#Använd nyckelordet using till Model.save() för att ange till vilken databas data ska sparas.
Om du t.ex. vill spara ett objekt i databasen legacy_users använder du följande:
>>> my_object.save(using="legacy_users")\nOm du inte anger using kommer metoden save() att spara i den standarddatabas som routrarna har tilldelat.
Om du har sparat en instans i en databas kan det vara frestande att använda save(using=...) som ett sätt att migrera instansen till en ny databas. Men om du inte vidtar lämpliga åtgärder kan detta få oväntade konsekvenser.
Tänk på följande exempel:
\n>>> p = Person(name="Fred")\n>>> p.save(using="first") # (statement 1)\n>>> p.save(using="second") # (statement 2)\nI uttalande 1 sparas ett nytt Person-objekt i databasen first. Vid denna tidpunkt har p ingen primärnyckel, så Django utfärdar en SQL INSERT-sats. Detta skapar en primärnyckel och Django tilldelar den primära nyckeln till p.
När sparandet sker i uttalande 2 har p redan ett primärnyckelvärde, och Django kommer att försöka använda den primärnyckeln i den nya databasen. Om det primära nyckelvärdet inte används i den andra databasen, kommer du inte att ha några problem - objektet kommer att kopieras till den nya databasen.
Men om primärnyckeln i p redan används i databasen second, kommer det befintliga objektet i databasen second att åsidosättas när p sparas.
Du kan undvika detta på två sätt. För det första kan du rensa instansens primära nyckel. Om ett objekt inte har någon primärnyckel kommer Django att behandla det som ett nytt objekt, vilket undviker förlust av data i andra databasen:
>>> p = Person(name="Fred")\n>>> p.save(using="first")\n>>> p.pk = None # Clear the primary key.\n>>> p.save(using="second") # Write a completely new object.\nDet andra alternativet är att använda alternativet force_insert till save() för att säkerställa att Django gör en SQL INSERT:
>>> p = Person(name="Fred")\n>>> p.save(using="first")\n>>> p.save(using="second", force_insert=True)\nDetta kommer att säkerställa att personen som heter Fred kommer att ha samma primärnyckel i båda databaserna. Om den primära nyckeln redan används när du försöker spara i den ”andra” databasen, kommer ett fel att uppstå.
Som standard kommer ett anrop för att ta bort ett befintligt objekt att utföras i samma databas som användes för att hämta objektet från första början:
\n>>> u = User.objects.using("legacy_users").get(username="fred")\n>>> u.delete() # will delete from the `legacy_users` database\nFör att ange databasen från vilken en modell ska raderas, skicka ett using nyckelordsargument till metoden Model.delete(). Detta argument fungerar precis som nyckelordsargumentet using till save().
Om du t.ex. ska flytta en användare från databasen legacy_users till databasen new_users kan du använda följande kommandon:
>>> user_obj.save(using="new_users")\n>>> user_obj.delete(using="legacy_users")\nAnvänd metoden db_manager() på managers för att ge managers tillgång till en databas som inte är standard.
Anta till exempel att du har en anpassad managermetod som berör databasen - User.objects.create_user(). Eftersom create_user() är en managermetod, inte en QuerySet-metod, kan du inte göra User.objects.using('new_users').create_user(). (Metoden create_user() är endast tillgänglig på User.objects, hanteraren, inte på QuerySet-objekt som härrör från hanteraren) Lösningen är att använda db_manager(), så här:
User.objects.db_manager("new_users").create_user(...)\ndb_manager() returnerar en kopia av den manager som är knuten till den databas du anger.
get_queryset() med flera databaserLink to this heading#Om du åsidosätter get_queryset() på din manager, se till att antingen anropa metoden på den överordnade (med super()) eller gör lämplig hantering av _db-attributet på managern (en sträng som innehåller namnet på den databas som ska användas).
Om du till exempel vill returnera en anpassad QuerySet-klass från get_queryset-metoden kan du göra så här:
class MyManager(models.Manager):\n def get_queryset(self):\n qs = CustomQuerySet(self.model)\n if self._db is not None:\n qs = qs.using(self._db)\n return qs\nDjangos admin har inte något uttryckligt stöd för flera databaser. Om du vill tillhandahålla ett administratörsgränssnitt för en modell på en annan databas än den som anges av din routerkedja måste du skriva anpassade ModelAdmin-klasser som kommer att styra administratören att använda en specifik databas för innehåll.
objekten ModelAdmin har följande metoder som kräver anpassning för stöd för flera databaser:
class MultiDBModelAdmin(admin.ModelAdmin):\n # A handy constant for the name of the alternate database.\n using = "other"\n\n def save_model(self, request, obj, form, change):\n # Tell Django to save objects to the 'other' database.\n obj.save(using=self.using)\n\n def delete_model(self, request, obj):\n # Tell Django to delete objects from the 'other' database\n obj.delete(using=self.using)\n\n def get_queryset(self, request):\n # Tell Django to look for objects on the 'other' database.\n return super().get_queryset(request).using(self.using)\n\n def formfield_for_foreignkey(self, db_field, request, **kwargs):\n # Tell Django to populate ForeignKey widgets using a query\n # on the 'other' database.\n return super().formfield_for_foreignkey(\n db_field, request, using=self.using, **kwargs\n )\n\n def formfield_for_manytomany(self, db_field, request, **kwargs):\n # Tell Django to populate ManyToMany widgets using a query\n # on the 'other' database.\n return super().formfield_for_manytomany(\n db_field, request, using=self.using, **kwargs\n )\nDen implementering som tillhandahålls här implementerar en strategi med flera databaser där alla objekt av en viss typ lagras i en specifik databas (t.ex. alla User-objekt finns i databasen other). Om din användning av flera databaser är mer komplex måste din ModelAdmin återspegla den strategin.
InlineModelAdmin-objekt kan hanteras på ett liknande sätt. De kräver tre anpassade metoder:
class MultiDBTabularInline(admin.TabularInline):\n using = "other"\n\n def get_queryset(self, request):\n # Tell Django to look for inline objects on the 'other' database.\n return super().get_queryset(request).using(self.using)\n\n def formfield_for_foreignkey(self, db_field, request, **kwargs):\n # Tell Django to populate ForeignKey widgets using a query\n # on the 'other' database.\n return super().formfield_for_foreignkey(\n db_field, request, using=self.using, **kwargs\n )\n\n def formfield_for_manytomany(self, db_field, request, **kwargs):\n # Tell Django to populate ManyToMany widgets using a query\n # on the 'other' database.\n return super().formfield_for_manytomany(\n db_field, request, using=self.using, **kwargs\n )\nNär du har skrivit dina modelladministratörsdefinitioner kan de registreras med valfri Admin-instans:
from django.contrib import admin\nfrom myapp.models import Author, Book, Publisher\n\n# Import our custom ModelAdmin and TabularInline from where they're defined.\nfrom myproject.admin import MultiDBModelAdmin, MultiDBTabularInline\n\n\n# Specialize the multi-db admin objects for use with specific models.\nclass BookInline(MultiDBTabularInline):\n model = Book\n\n\nclass PublisherAdmin(MultiDBModelAdmin):\n inlines = [BookInline]\n\n\nadmin.site.register(Author, MultiDBModelAdmin)\nadmin.site.register(Publisher, PublisherAdmin)\n\nothersite = admin.AdminSite("othersite")\nothersite.register(Publisher, MultiDBModelAdmin)\nI detta exempel skapas två administratörswebbplatser. På den första webbplatsen exponeras objekten Author och Publisher; Publisher-objekten har en tabulär inline som visar böcker som publicerats av det förlaget. Den andra webbplatsen exponerar bara förläggare, utan inlines.
Om du använder mer än en databas kan du använda django.db.connections för att få anslutningen (och markören) för en specifik databas. django.db.connections är ett ordboksliknande objekt som gör att du kan hämta en specifik anslutning med hjälp av dess alias:
from django.db import connections\n\nwith connections["my_db_alias"].cursor() as cursor:\n ...\nDjango ger för närvarande inget stöd för foreign key eller many-to-many-relationer som sträcker sig över flera databaser. Om du har använt en router för att partitionera modeller till olika databaser måste alla foreign key- och many-to-many-relationer som definieras av dessa modeller vara interna i en enda databas.
\nDetta beror på referentiell integritet. För att kunna upprätthålla en relation mellan två objekt måste Django veta att primärnyckeln för det relaterade objektet är giltig. Om primärnyckeln lagras i en separat databas är det inte möjligt att enkelt utvärdera giltigheten för en primärnyckel.
\nOm du använder Postgres, SQLite, Oracle eller MySQL med InnoDB verkställs detta på databasintegritetsnivå - nyckelbegränsningar på databasnivå förhindrar att relationer skapas som inte kan valideras.
\nMen om du använder MySQL med MyISAM-tabeller finns det ingen påtvingad referensintegritet; som ett resultat kan du kanske ”fejka” utländska nycklar i korsdatabasen. Denna konfiguration stöds dock inte officiellt av Django.
\nFlera Contrib-appar innehåller modeller, och vissa appar är beroende av andra. Eftersom relationer mellan databaser är omöjliga skapar detta vissa begränsningar för hur du kan dela dessa modeller mellan olika databaser:
\nvar och en av contenttypes.ContentType, sessions.Session och sites.Site kan lagras i vilken databas som helst, förutsatt att en lämplig router används.
auth-modellerna - User, Group och Permission - är sammanlänkade och länkade till ContentType, så de måste lagras i samma databas som ContentType.
admin är beroende av auth, så dess modeller måste finnas i samma databas som auth.
flatpages och redirects är beroende av sites, så deras modeller måste finnas i samma databas som sites.
Dessutom skapas vissa objekt automatiskt strax efter att migrate har skapat en tabell för att hålla dem i en databas:
en förvald Site,
en ContentType för varje modell (även de som inte finns lagrade i databasen),
”Tillstånd” för varje modell (även de som inte lagras i databasen).
För vanliga konfigurationer med flera databaser är det inte användbart att ha dessa objekt i mer än en databas. Vanliga konfigurationer inkluderar primär/replika och anslutning till externa databaser. Därför rekommenderas det att skriva en databasrouter som gör det möjligt att synkronisera dessa tre modeller till endast en databas. Använd samma tillvägagångssätt för contrib- och tredjepartsappar som inte behöver sina tabeller i flera databaser.
\n\n