En Manager är det gränssnitt genom vilket databasfrågeoperationer tillhandahålls till Django-modeller. Det finns minst en Manager för varje modell i en Django-applikation.
Hur klasserna Manager fungerar finns dokumenterat i Göra förfrågningar; detta dokument tar specifikt upp modellalternativ som anpassar Manager beteende.
Som standard lägger Django till en Manager med namnet objects till varje Django modellklass. Men om du vill använda objects som fältnamn, eller om du vill använda ett annat namn än objects för Manager, kan du byta namn på den per modell. Om du vill byta namn på Manager för en viss klass definierar du ett klassattribut av typen models.Manager() för den modellen. Till exempel:
from django.db import models\n\n\nclass Person(models.Model):\n # ...\n people = models.Manager()\nMed hjälp av denna exempelmodell kommer Person.objects att generera ett AttributeError undantag, men Person.people.all() kommer att ge en lista över alla Person objekt.
Du kan använda en anpassad Manager i en viss modell genom att utöka basklassen Manager och instansiera din anpassade Manager i din modell.
Det finns två anledningar till att du vill anpassa en Manager: att lägga till extra Manager-metoder och/eller att ändra den första QuerySet som Manager returnerar.
Att lägga till extra Manager-metoder är det bästa sättet att lägga till funktionalitet på ”tabellnivå” i dina modeller. (För funktioner på ”radnivå”, dvs. funktioner som verkar på en enda instans av ett modellobjekt, ska du använda Model methods, inte anpassade Manager-metoder)
Till exempel lägger den här anpassade Manager till en metod with_counts():
from django.db import models\nfrom django.db.models.functions import Coalesce\n\n\nclass PollManager(models.Manager):\n def with_counts(self):\n return self.annotate(num_responses=Coalesce(models.Count("response"), 0))\n\n\nclass OpinionPoll(models.Model):\n question = models.CharField(max_length=200)\n objects = PollManager()\n\n\nclass Response(models.Model):\n poll = models.ForeignKey(OpinionPoll, on_delete=models.CASCADE)\n # ...\nI det här exemplet skulle du använda OpinionPoll.objects.with_counts() för att få en QuerySet av OpinionPoll-objekt med det extra attributet num_responses.
En anpassad Manager-metod kan returnera vad du vill. Den behöver inte returnera en QuerySet.
En annan sak att notera är att Manager-metoder kan komma åt self.model för att hämta den modellklass som de är kopplade till.
QuerySetLink to this heading#En Manager’s bas QuerySet returnerar alla objekt i systemet. Till exempel, med hjälp av denna modell:
from django.db import models\n\n\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n author = models.CharField(max_length=50)\n…kommer uttalandet Book.objects.all() att returnera alla böcker i databasen.
Du kan åsidosätta en Manager’s bas QuerySet genom att åsidosätta metoden Manager.get_queryset(). get_queryset() bör returnera en QuerySet med de egenskaper du behöver.
Till exempel har följande modell två Manager - en som returnerar alla objekt och en som bara returnerar böckerna av Roald Dahl:
# First, define the Manager subclass.\nclass DahlBookManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(author="Roald Dahl")\n\n\n# Then hook it into the Book model explicitly.\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n author = models.CharField(max_length=50)\n\n objects = models.Manager() # The default manager.\n dahl_objects = DahlBookManager() # The Dahl-specific manager.\nMed den här exempelmodellen kommer Book.objects.all() att returnera alla böcker i databasen, men Book.dahl_objects.all() kommer bara att returnera de som är skrivna av Roald Dahl.
Eftersom get_queryset() returnerar ett QuerySet-objekt kan du använda filter(), exclude() och alla andra QuerySet-metoder på det. Så dessa uttalanden är alla lagliga:
Book.dahl_objects.all()\nBook.dahl_objects.filter(title="Matilda")\nBook.dahl_objects.count()\nDetta exempel visade också på en annan intressant teknik: att använda flera managers på samma modell. Du kan koppla så många Manager()-instanser till en modell som du vill. Detta är ett icke-repetitivt sätt att definiera gemensamma ”filter” för dina modeller.
Till exempel:
\nclass AuthorManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(role="A")\n\n\nclass EditorManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(role="E")\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n role = models.CharField(max_length=1, choices={"A": _("Author"), "E": _("Editor")})\n people = models.Manager()\n authors = AuthorManager()\n editors = EditorManager()\nI det här exemplet kan du begära Person.authors.all(), Person.editors.all() och Person.people.all(), vilket ger förutsägbara resultat.
Om du använder anpassade Manager-objekt, notera att den första Manager som Django stöter på (i den ordning de definieras i modellen) har en speciell status. Django tolkar den första Manager som definieras i en klass som ”standard” Manager, och flera delar av Django (inklusive dumpdata) kommer att använda den Manager exklusivt för den modellen. Som ett resultat är det en bra idé att vara försiktig i ditt val av standardhanterare för att undvika en situation där åsidosättande av get_queryset() resulterar i en oförmåga att hämta objekt som du vill arbeta med.
Du kan ange en anpassad standardhanterare med Meta.default_manager_name <django.db.models.Options.default_manager_name>`.
Om du skriver kod som måste hantera en okänd modell, t.ex. i en tredjepartsapp som implementerar en generisk vy, ska du använda den här hanteraren (eller _base_manager) i stället för att anta att modellen har en objects-hanterare.
Denna manager används för att komma åt objekt som är relaterade till från någon annan modell. I dessa situationer måste Django kunna se alla objekt för den modell som hämtas, så att allt som hänvisas till kan hämtas.
\nDärför bör du inte åsidosätta get_queryset() för att filtrera bort några rader. Om du gör det kommer Django att returnera ofullständiga resultat.
QuerySet från hanterarenLink to this heading#Medan de flesta metoder från standard QuerySet är tillgängliga direkt från Manager, är detta endast fallet för de extra metoder som definieras på en anpassad QuerySet om du också implementerar dem på Manager:
class PersonQuerySet(models.QuerySet):\n def authors(self):\n return self.filter(role="A")\n\n def editors(self):\n return self.filter(role="E")\n\n\nclass PersonManager(models.Manager):\n def get_queryset(self):\n return PersonQuerySet(self.model, using=self._db)\n\n def authors(self):\n return self.get_queryset().authors()\n\n def editors(self):\n return self.get_queryset().editors()\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n role = models.CharField(max_length=1, choices={"A": _("Author"), "E": _("Editor")})\n people = PersonManager()\nI det här exemplet kan du anropa både authors() och editors() direkt från hanteraren Person.people.
QuerySet-metoderLink to this heading#I stället för ovanstående tillvägagångssätt som kräver duplicering av metoder på både QuerySet och Manager, QuerySet.as_manager() kan användas för att skapa en instans av Manager med en kopia av en anpassad QuerySet’s metoder:
class Person(models.Model):\n ...\n people = PersonQuerySet.as_manager()\nInstansen Manager som skapas av QuerySet.as_manager() kommer att vara praktiskt taget identisk med PersonManager från föregående exempel.
Inte alla QuerySet -metoder är meningsfulla på Manager -nivån; till exempel förhindrar vi avsiktligt QuerySet.delete() -metoden från att kopieras till Manager -klassen.
Metoderna kopieras enligt följande regler:
\nPublika metoder kopieras som standard.
Privata metoder (som börjar med en understrykning) kopieras inte som standard.
Metoder med attributet queryset_only inställt på False kopieras alltid.
Metoder med attributet queryset_only inställt på True kopieras aldrig.
Till exempel:
\nclass CustomQuerySet(models.QuerySet):\n # Available on both Manager and QuerySet.\n def public_method(self):\n return\n\n # Available only on QuerySet.\n def _private_method(self):\n return\n\n # Available only on QuerySet.\n def opted_out_public_method(self):\n return\n\n opted_out_public_method.queryset_only = True\n\n # Available on both Manager and QuerySet.\n def _opted_in_private_method(self):\n return\n\n _opted_in_private_method.queryset_only = False\nfrom_queryset()Link to this heading#För avancerad användning kanske du vill ha både en anpassad Manager och en anpassad QuerySet. Du kan göra det genom att anropa Manager.from_queryset() som returnerar en subklass av din bas Manager med en kopia av de anpassade QuerySet metoderna:
class CustomManager(models.Manager):\n def manager_only_method(self):\n return\n\n\nclass CustomQuerySet(models.QuerySet):\n def manager_and_queryset_method(self):\n return\n\n\nclass MyModel(models.Model):\n objects = CustomManager.from_queryset(CustomQuerySet)()\nDu kan också lagra den genererade klassen i en variabel:
\nMyManager = CustomManager.from_queryset(CustomQuerySet)\n\n\nclass MyModel(models.Model):\n objects = MyManager()\nSå här hanterar Django egna managers och modellarv:
\nHanterare från basklasser ärvs alltid av underklassen, med Pythons normala namnupplösningsordning (namn på underklassen åsidosätter alla andra; sedan kommer namn på den första föräldraklassen, och så vidare).
Om inga managers deklareras på en modell och/eller dess föräldrar skapar Django automatiskt manager objects.
Standardhanteraren för en klass är antingen den som valts med Meta.default_manager_name, eller den första hanteraren som deklarerats på modellen, eller standardhanteraren för den första överordnade modellen.
Dessa regler ger den flexibilitet som krävs om du vill installera en samling anpassade hanterare på en grupp modeller, via en abstrakt basklass, men ändå anpassa standardhanteraren. Anta till exempel att du har den här basklassen:
\nclass AbstractBase(models.Model):\n # ...\n objects = CustomManager()\n\n class Meta:\n abstract = True\nOm du använder detta direkt i en underordnad klass kommer objects att vara standardhanteraren om du inte deklarerar några hanterare i den underordnade klassen:
class ChildA(AbstractBase):\n # ...\n # This class has CustomManager as the default manager.\n pass\nOm du vill ärva från AbstractBase, men tillhandahålla en annan standardhanterare, kan du ange standardhanteraren på barnklassen:
class ChildB(AbstractBase):\n # ...\n # An explicit default manager.\n default_manager = OtherManager()\nHär är default_manager standard. Hanteraren objects är fortfarande tillgänglig, eftersom den ärvs, men används inte som standard.
Slutligen för det här exemplet, anta att du vill lägga till extra chefer i barnklassen, men fortfarande använda standard från AbstractBase. Du kan inte lägga till den nya hanteraren direkt i barnklassen, eftersom det skulle åsidosätta standardvärdet och du måste också uttryckligen inkludera alla hanterare från den abstrakta basklassen. Lösningen är att lägga de extra förvaltarna i en annan basklass och införa den i arvshierarkin efter standardvärdena:
class ExtraManager(models.Model):\n extra_manager = OtherManager()\n\n class Meta:\n abstract = True\n\n\nclass ChildC(AbstractBase, ExtraManager):\n # ...\n # Default manager is CustomManager, but OtherManager is\n # also available via the "extra_manager" attribute.\n pass\nObservera att även om du kan definiera en anpassad manager på den abstrakta modellen, kan du inte invoke några metoder som använder den abstrakta modellen. Det vill säga:
\nClassA.objects.do_something()\när lagligt, men:
\nAbstractBase.objects.do_something()\nkommer att ge upphov till ett undantag. Detta beror på att managers är avsedda att kapsla in logik för att hantera samlingar av objekt. Eftersom du inte kan ha en samling av abstrakta objekt är det inte meningsfullt att hantera dem. Om du har funktionalitet som gäller för den abstrakta modellen bör du lägga den funktionaliteten i en staticmethod eller classmethod på den abstrakta modellen.
Oavsett vilka funktioner du lägger till i din anpassade Manager måste det vara möjligt att göra en ytlig kopia av en Manager-instans, dvs. följande kod måste fungera:
>>> import copy\n>>> manager = MyManager()\n>>> my_copy = copy.copy(manager)\nDjango gör ytliga kopior av managerobjekt under vissa frågor; om din manager inte kan kopieras kommer dessa frågor att misslyckas.
\nDetta kommer inte att vara ett problem för de flesta anpassade förvaltare. Om du bara lägger till enkla metoder till din Manager är det osannolikt att du oavsiktligt kommer att göra instanser av din Manager okopierbara. Men om du åsidosätter __getattr__ eller någon annan privat metod i ditt Manager-objekt som kontrollerar objektets tillstånd, bör du se till att du inte påverkar möjligheten för din Manager att kopieras.