Django innehåller en contenttypes-applikation som kan spåra alla modeller som är installerade i ditt Django-drivna projekt, vilket ger ett generiskt gränssnitt på hög nivå för att arbeta med dina modeller.
Kärnan i contenttypes-applikationen är modellen ContentType, som finns i django.contrib.contenttypes.models.ContentType. Instanser av ContentType representerar och lagrar information om de modeller som är installerade i ditt projekt, och nya instanser av ContentType skapas automatiskt när nya modeller installeras.
Instanser av ContentType har metoder för att returnera de modellklasser de representerar och för att fråga objekt från dessa modeller. ContentType har också en custom manager som lägger till metoder för att arbeta med ContentType och för att erhålla instanser av ContentType för en viss modell.
Relationer mellan dina modeller och ContentType kan också användas för att aktivera ”generiska” relationer mellan en instans av en av dina modeller och instanser av alla modeller du har installerat.
Contenttypes-ramverket ingår i standard INSTALLED_APPS-listan som skapats av django-admin startproject, men om du har tagit bort det eller om du manuellt ställer in din INSTALLED_APPS-lista kan du aktivera det genom att lägga till 'django.contrib.contenttypes' till din INSTALLED_APPS-inställning.
Det är i allmänhet en bra idé att ha contenttypes-ramverket installerat; flera av Djangos andra medföljande applikationer kräver det:
\nAdmin-programmet använder den för att logga historiken för varje objekt som läggs till eller ändras via admin-gränssnittet.
Djangos autentiseringsramverk använder det för att knyta användarrättigheter till specifika modeller.
ContentType (innehållstyp)Link to this heading#Varje instans av ContentType har två fält som tillsammans ger en unik beskrivning av en installerad modell:
Namnet på den applikation som modellen är en del av. Detta tas från app_label-attributet för modellen och inkluderar endast den sista delen av applikationens Python-importväg; django.contrib.contenttypes, till exempel, blir en app_label av contenttypes.
Namnet på modellklassen.
\nDessutom är följande egendom tillgänglig:
\nDet mänskliga läsbara namnet på innehållstypen. Detta hämtas från attributet verbose_name i modellen.
Låt oss titta på ett exempel för att se hur detta fungerar. Om du redan har contenttypes-programmet installerat, och sedan lägger till the sites application till din INSTALLED_APPS-inställning och kör manage.py migrate för att installera det, kommer modellen django.contrib.sites.models.Site att installeras i din databas. Tillsammans med det kommer en ny instans av ContentType att skapas med följande värden:
ContentTypeLink to this heading#Varje ContentType-instans har metoder som gör att du kan komma från en ContentType-instans till den modell den representerar, eller för att hämta objekt från den modellen:
Tar en uppsättning giltiga uppslagsargument för den modell som ContentType representerar, och gör en get()-uppslagning på den modellen och returnerar motsvarande objekt. Argumentet using kan användas för att ange en annan databas än standarddatabasen.
Returnerar den modellklass som representeras av denna ContentType-instans.
Vi kan till exempel leta upp ContentType för modellen User:
>>> from django.contrib.contenttypes.models import ContentType\n>>> user_type = ContentType.objects.get(app_label="auth", model="user")\n>>> user_type\n<ContentType: user>\nOch sedan använda den för att fråga efter en viss User, eller för att få tillgång till modellklassen User:
>>> user_type.model_class()\n<class 'django.contrib.auth.models.User'>\n>>> user_type.get_object_for_this_type(username="Guido")\n<User: Guido>\nTillsammans möjliggör get_object_for_this_type() och model_class() två extremt viktiga användningsfall:
Med hjälp av dessa metoder kan du skriva generisk kod på hög nivå som utför frågor på alla installerade modeller - istället för att importera och använda en enda specifik modellklass kan du skicka en app_label och model till en ContentType-uppslagning vid körning och sedan arbeta med modellklassen eller hämta objekt från den.
Du kan relatera en annan modell till ContentType som ett sätt att binda instanser av den till särskilda modellklasser, och använda dessa metoder för att få åtkomst till dessa modellklasser.
Flera av Djangos medföljande applikationer använder sig av den senare tekniken. Till exempel: använder behörighetssystemet i Djangos autentiseringsramverk en Permission-modell med en främmande nyckel till ContentType; detta låter Permission representera koncept som ”kan lägga till blogginlägg” eller ”kan ta bort nyhetsartikel”.
ContentType har också en anpassad manager, ContentTypeManager, som lägger till följande metoder:
Rensar en intern cache som används av ContentType för att hålla reda på modeller för vilka den har skapat ContentType-instanser. Du kommer förmodligen aldrig att behöva anropa den här metoden själv; Django kommer att anropa den automatiskt när den behövs.
Leta upp en ContentType efter ID. Eftersom denna metod använder samma delade cache som get_for_model(), är det att föredra att använda denna metod framför den vanliga ContentType.objects.get(pk=id)
Tar antingen en modellklass eller en instans av en modell och returnerar ContentType-instansen som representerar den modellen. for_concrete_model=False tillåter hämtning av ContentType för en proxymodell.
Tar ett variabelt antal modellklasser och returnerar en ordbok som mappar modellklasserna till ContentType-instanser som representerar dem. for_concrete_models=False tillåter hämtning av ContentType för proxymodeller.
Returnerar ContentType-instansen som identifieras unikt av den angivna applikationsetiketten och modellnamnet. Det primära syftet med denna metod är att tillåta att ContentType-objekt refereras via en naturlig nyckel under deserialisering.
Metoden get_for_model() är särskilt användbar när du vet att du behöver arbeta med en ContentType men inte vill göra dig besväret att hämta modellens metadata för att utföra en manuell sökning:
>>> from django.contrib.auth.models import User\n>>> ContentType.objects.get_for_model(User)\n<ContentType: user>\nGenom att lägga till en främmande nyckel från en av dina egna modeller till ContentType kan din modell effektivt binda sig till en annan modellklass, som i exemplet med modellen Permission ovan. Men det är möjligt att gå ett steg längre och använda ContentType för att möjliggöra verkligt generiska (ibland kallade ”polymorfa”) relationer mellan modeller.
Det kan till exempel användas för ett taggningssystem på följande sätt:
\nfrom django.contrib.contenttypes.fields import GenericForeignKey\nfrom django.contrib.contenttypes.models import ContentType\nfrom django.db import models\n\n\nclass TaggedItem(models.Model):\n tag = models.SlugField()\n content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)\n object_id = models.PositiveBigIntegerField()\n content_object = GenericForeignKey("content_type", "object_id")\n\n def __str__(self):\n return self.tag\n\n class Meta:\n indexes = [\n models.Index(fields=["content_type", "object_id"]),\n ]\nEn normal ForeignKey kan bara ”peka på” en annan modell, vilket innebär att om modellen TaggedItem använde en ForeignKey skulle den behöva välja en och endast en modell att lagra taggar för. Contenttypes-applikationen tillhandahåller en speciell fälttyp (GenericForeignKey) som kringgår detta och gör att relationen kan vara med vilken modell som helst:
Det finns tre delar för att konfigurera en GenericForeignKey:
Ge din modell en ForeignKey till ContentType. Det vanliga namnet för detta fält är ”content_type”.
Ge din modell ett fält som kan lagra primära nyckelvärden från de modeller du kommer att relatera till. För de flesta modeller innebär detta en PositiveBigIntegerField. Det vanliga namnet för detta fält är ”object_id”.
Ge din modell en GenericForeignKey, och skicka den namnen på de två fälten som beskrivs ovan. Om dessa fält heter ”content_type” och ”object_id” kan du utelämna detta - det är standardfältens namn som GenericForeignKey kommer att leta efter.
Till skillnad från ForeignKey, skapas inte automatiskt ett databasindex för GenericForeignKey, så det rekommenderas att du använder Meta.indexes för att lägga till ditt eget index med flera kolumner. Detta beteende kan komma att ändras i framtiden.
Om False, kommer fältet att kunna referera till proxy-modeller. Standard är True. Detta speglar argumentet for_concrete_model till get_for_model().
Detta kommer att möjliggöra ett API som liknar det som används för en vanlig ForeignKey; varje TaggedItem kommer att ha ett content_object-fält som returnerar det objekt som det är relaterat till, och du kan också tilldela det fältet eller använda det när du skapar en TaggedItem:
>>> from django.contrib.auth.models import User\n>>> guido = User.objects.get(username="Guido")\n>>> t = TaggedItem(content_object=guido, tag="bdfl")\n>>> t.save()\n>>> t.content_object\n<User: Guido>\nOm det relaterade objektet tas bort, förblir fälten content_type och object_id inställda på sina ursprungliga värden och GenericForeignKey returnerar None:
>>> guido.delete()\n>>> t.content_object # returns None\nPå grund av hur GenericForeignKey implementeras kan du inte använda sådana fält direkt med filter (filter() och exclude(), till exempel) via databas-API:et. Eftersom en GenericForeignKey inte är ett normalt fältobjekt, kommer dessa exempel inte att fungera:
# This will fail\n>>> TaggedItem.objects.filter(content_object=guido)\n# This will also fail\n>>> TaggedItem.objects.get(content_object=guido)\nPå samma sätt visas inte GenericForeignKeys i ModelForms.
Relationen från det relaterade objektet tillbaka till detta objekt existerar inte som standard. Om du ställer in related_query_name skapas en relation från det relaterade objektet tillbaka till detta. Detta gör det möjligt att ställa frågor och filtrera från det relaterade objektet.
Om du vet vilka modeller du kommer att använda oftast kan du också lägga till en ”omvänd” generisk relation för att aktivera ytterligare ett API. Till exempel:
\nfrom django.contrib.contenttypes.fields import GenericRelation\nfrom django.db import models\n\n\nclass Bookmark(models.Model):\n url = models.URLField()\n tags = GenericRelation(TaggedItem)\n”Bokmärkes”-instanser har alla ett ”tags”-attribut, som kan användas för att hämta deras associerade ”tagged items”:
\n>>> b = Bookmark(url="https://www.djangoproject.com/")\n>>> b.save()\n>>> t1 = TaggedItem(content_object=b, tag="django")\n>>> t1.save()\n>>> t2 = TaggedItem(content_object=b, tag="python")\n>>> t2.save()\n>>> b.tags.all()\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nDu kan också använda add(), create() eller set() för att skapa relationer:
>>> t3 = TaggedItem(tag="Web development")\n>>> b.tags.add(t3, bulk=False)\n>>> b.tags.create(tag="Web framework")\n<TaggedItem: Web framework>\n>>> b.tags.all()\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>, <TaggedItem: Web development>, <TaggedItem: Web framework>]>\n>>> b.tags.set([t1, t3])\n>>> b.tags.all()\n<QuerySet [<TaggedItem: django>, <TaggedItem: Web development>]>\nAnropet remove() raderar de angivna modellobjekten i bulk:
>>> b.tags.remove(t3)\n>>> b.tags.all()\n<QuerySet [<TaggedItem: django>]>\n>>> TaggedItem.objects.all()\n<QuerySet [<TaggedItem: django>]>\nMetoden clear() kan användas för att massradera alla relaterade objekt för en instans:
>>> b.tags.clear()\n>>> b.tags.all()\n<QuerySet []>\n>>> TaggedItem.objects.all()\n<QuerySet []>\nGenom att definiera GenericRelation med related_query_name kan man ställa frågor från det relaterade objektet:
tags = GenericRelation(TaggedItem, related_query_name="bookmark")\nDetta möjliggör filtrering, ordning och andra frågeoperationer på Bookmark från TaggedItem:
>>> # Get all tags belonging to bookmarks containing `django` in the url\n>>> TaggedItem.objects.filter(bookmark__url__contains="django")\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nOm du inte lägger till related_query_name kan du göra samma typer av uppslagningar manuellt:
>>> bookmarks = Bookmark.objects.filter(url__contains="django")\n>>> bookmark_type = ContentType.objects.get_for_model(Bookmark)\n>>> TaggedItem.objects.filter(content_type__pk=bookmark_type.id, object_id__in=bookmarks)\n<QuerySet [<TaggedItem: django>, <TaggedItem: python>]>\nPrecis som GenericForeignKey accepterar namnen på fälten content-type och object-ID som argument, så gör även GenericRelation det; om modellen som har den generiska främmande nyckeln använder icke-standardnamn för dessa fält, måste du skicka namnen på fälten när du ställer in en GenericRelation till den. Om t.ex. modellen TaggedItem som nämns ovan använder fält med namnen content_type_fk och object_primary_key för att skapa sin generiska främmande nyckel, måste en GenericRelation tillbaka till den definieras på följande sätt:
tags = GenericRelation(\n TaggedItem,\n content_type_field="content_type_fk",\n object_id_field="object_primary_key",\n)\nObservera också att om du tar bort ett objekt som har en GenericRelation, kommer alla objekt som har en GenericForeignKey som pekar på det också att tas bort. I exemplet ovan innebär detta att om ett Bookmark-objekt raderas, kommer alla TaggedItem-objekt som pekar på det att raderas samtidigt.
Till skillnad från ForeignKey accepterar GenericForeignKey inte ett on_delete-argument för att anpassa detta beteende; om så önskas kan du undvika kaskadradering genom att inte använda GenericRelation, och alternativt beteende kan tillhandahållas via pre_delete-signalen.
Djangos API för databasaggregering fungerar med en GenericRelation. Du kan till exempel ta reda på hur många taggar alla bokmärken har:
>>> Bookmark.objects.aggregate(Count("tags"))\n{'tags__count': 3}\nModulen django.contrib.contenttypes.forms tillhandahåller:
En formulärfabrik, generic_inlineformset_factory(), för användning med GenericForeignKey.
Returnerar en GenericInlineFormSet med modelformset_factory().
Du måste ange ct_field och fk_field om de skiljer sig från standardvärdena, content_type respektive object_id. Andra parametrar liknar de som dokumenteras i modelformset_factory() och inlineformset_factory().
Argumentet for_concrete_model motsvarar argumentet for_concrete_model på GenericForeignKey.
Modulen django.contrib.contenttypes.admin tillhandahåller GenericTabularInline och GenericStackedInline (underklasser till GenericInlineModelAdmin)
Dessa klasser och funktioner gör det möjligt att använda generiska relationer i formulär och i admin. Se dokumentationen model formset och admin för mer information.
\nKlassen GenericInlineModelAdmin ärver alla egenskaper från klassen InlineModelAdmin. Den lägger dock till ett par egna för att arbeta med den generiska relationen:
Namnet på ContentType främmande nyckelfält på modellen. Standardvärdet är content_type.
Namnet på det heltalsfält som representerar ID:t för det relaterade objektet. Standardvärdet är object_id.
Underklasser till GenericInlineModelAdmin med staplad respektive tabulär layout.
GeneriskPrefetch()Link to this heading#Denna sökning liknar Prefetch() och den bör endast användas på GenericForeignKey. Argumentet querysets accepterar en lista med querysets, var och en för en annan ContentType. Detta är användbart för GenericForeignKey med icke-homogena uppsättningar resultat.
>>> from django.contrib.contenttypes.prefetch import GenericPrefetch\n>>> bookmark = Bookmark.objects.create(url="https://www.djangoproject.com/")\n>>> animal = Animal.objects.create(name="lion", weight=100)\n>>> TaggedItem.objects.create(tag="great", content_object=bookmark)\n>>> TaggedItem.objects.create(tag="awesome", content_object=animal)\n>>> prefetch = GenericPrefetch(\n... "content_object", [Bookmark.objects.all(), Animal.objects.only("name")]\n... )\n>>> TaggedItem.objects.prefetch_related(prefetch).all()\n<QuerySet [<TaggedItem: Great>, <TaggedItem: Awesome>]>\n