Det här dokumentet innehåller alla API-referenser för Field inklusive de field options och field types som Django erbjuder.
Följande argument är tillgängliga för alla fälttyper. Alla är valfria.
\nnullLink to this heading#Om True, kommer Django att lagra tomma värden som NULL i databasen. Standard är False.
Undvik att använda null på strängbaserade fält som CharField och TextField. Django-konventionen är att använda en tom sträng, inte NULL, som ”inga data”-tillstånd för strängbaserade fält. Om ett strängbaserat fält har null=False kan tomma strängar fortfarande sparas för ”inga data”. Om ett strängbaserat fält har null=True, betyder det att det har två möjliga värden för ”no data”: NULL och den tomma strängen. I de flesta fall är det överflödigt att ha två möjliga värden för ”no data”. Ett undantag är när en CharField har både unique=True och blank=True inställda. I den här situationen krävs null=True för att undvika brott mot unika begränsningar när flera objekt med tomma värden sparas.
För både strängbaserade och icke-strängbaserade fält måste du också ange blank=True om du vill tillåta tomma värden i formulär, eftersom parametern null endast påverkar databaslagring (se blank).
blankLink to this heading#Om True, får fältet vara tomt. Standard är False.
Observera att detta skiljer sig från null. null är rent databasrelaterat, medan blank är valideringsrelaterat. Om ett fält har blank=True, tillåter formulärvalidering att ett tomt värde anges. Om ett fält har blank=False kommer fältet att vara obligatoriskt.
valLink to this heading#En mappning eller iterabel i det format som beskrivs nedan för att användas som val för detta fält. Om val anges, verkställs de av modellvalidering och standardformulärwidgeten kommer att vara en valbox med dessa val istället för standardtextfältet.
\nOm en mappning anges är nyckelelementet det faktiska värde som ska anges i modellen och det andra elementet är det lättlästa namnet. Till exempel:
\nYEAR_IN_SCHOOL_CHOICES = {\n "FR": "Freshman",\n "SO": "Sophomore",\n "JR": "Junior",\n "SR": "Senior",\n "GR": "Graduate",\n}\nDu kan också skicka en sequence som i sig består av iterabler med exakt två element (t.ex. [(A1, B1), (A2, B2), ...]). Det första elementet i varje tupel är det faktiska värde som ska anges i modellen, och det andra elementet är det mänskligt läsbara namnet. Till exempel:
YEAR_IN_SCHOOL_CHOICES = [\n ("FR", "Freshman"),\n ("SO", "Sophomore"),\n ("JR", "Junior"),\n ("SR", "Senior"),\n ("GR", "Graduate"),\n]\nchoices kan också definieras som en callable som inte förväntar sig några argument och som returnerar något av de format som beskrivs ovan. Till exempel:
def get_currencies():\n return {i: i for i in settings.CURRENCIES}\n\n\nclass Expense(models.Model):\n amount = models.DecimalField(max_digits=10, decimal_places=2)\n currency = models.CharField(max_length=3, choices=get_currencies)\nAtt skicka en callable för choices kan vara särskilt praktiskt när, till exempel, alternativen är:
resultatet av I/O-bundna operationer (som potentiellt kan cachas), t.ex. att fråga en tabell i samma eller en extern databas, eller att komma åt val från en statisk fil.
en lista som för det mesta är stabil men som kan variera från tid till annan eller från projekt till projekt. Exempel i denna kategori är att använda tredjepartsappar som tillhandahåller en välkänd förteckning över värden, t.ex. valutor, länder, språk, tidszoner etc.
I allmänhet är det bäst att definiera val i en modellklass och att definiera en konstant med lämpligt namn för varje värde:
\nfrom django.db import models\n\n\nclass Student(models.Model):\n FRESHMAN = "FR"\n SOPHOMORE = "SO"\n JUNIOR = "JR"\n SENIOR = "SR"\n GRADUATE = "GR"\n YEAR_IN_SCHOOL_CHOICES = {\n FRESHMAN: "Freshman",\n SOPHOMORE: "Sophomore",\n JUNIOR: "Junior",\n SENIOR: "Senior",\n GRADUATE: "Graduate",\n }\n year_in_school = models.CharField(\n max_length=2,\n choices=YEAR_IN_SCHOOL_CHOICES,\n default=FRESHMAN,\n )\n\n def is_upperclass(self):\n return self.year_in_school in {self.JUNIOR, self.SENIOR}\nDu kan definiera en lista med val utanför en modellklass och sedan hänvisa till den, men om du definierar valen och namnen för varje val i modellklassen behålls all denna information i den klass som använder den och hjälper till att hänvisa till valen (t.ex. fungerar Student.SOPHOMORE överallt där modellen Student har importerats).
Du kan också samla dina tillgängliga val i namngivna grupper som kan användas för organisatoriska ändamål:
\nMEDIA_CHOICES = {\n "Audio": {\n "vinyl": "Vinyl",\n "cd": "CD",\n },\n "Video": {\n "vhs": "VHS Tape",\n "dvd": "DVD",\n },\n "unknown": "Unknown",\n}\nMappningens nyckel är det namn som ska användas för gruppen och värdet är alternativen i gruppen, som består av fältvärdet och ett lättläst namn för ett alternativ. Grupperade alternativ kan kombineras med ogrupperade alternativ i en enda mappning (som alternativet "unknown" i det här exemplet).
Du kan också använda en sekvens, t.ex. en lista med 2-tupler:
\nMEDIA_CHOICES = [\n (\n "Audio",\n (\n ("vinyl", "Vinyl"),\n ("cd", "CD"),\n ),\n ),\n (\n "Video",\n (\n ("vhs", "VHS Tape"),\n ("dvd", "DVD"),\n ),\n ),\n ("unknown", "Unknown"),\n]\nObservera att val kan vara vilket sekvensobjekt som helst - inte nödvändigtvis en lista eller tupel. Detta gör att du kan konstruera val dynamiskt. Men om du hackar choices för att vara dynamisk, är det förmodligen bättre att använda en riktig databastabell med en ForeignKey. choices är avsedd för statiska data som inte ändras mycket, om ens någonsin.
För varje modellfält som har choices inställt, kommer Django att normalisera valen till en lista med 2-tuples och lägga till en metod för att hämta det mänskliga läsbara namnet för fältets aktuella värde. Se get_FOO_display() i API-dokumentationen för databasen.
Om inte blank=False anges för fältet tillsammans med default kommer en etikett som innehåller "---------" att återges med valboxen. Om du vill åsidosätta detta beteende lägger du till en tupel i choices som innehåller None, t.ex. (None, 'Your String For Display'). Alternativt kan du använda en tom sträng istället för None där detta är meningsfullt - till exempel på en CharField.
Dessutom tillhandahåller Django enumerationstyper som du kan underklassa för att definiera val på ett koncist sätt:
\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass Student(models.Model):\n class YearInSchool(models.TextChoices):\n FRESHMAN = "FR", _("Freshman")\n SOPHOMORE = "SO", _("Sophomore")\n JUNIOR = "JR", _("Junior")\n SENIOR = "SR", _("Senior")\n GRADUATE = "GR", _("Graduate")\n\n year_in_school = models.CharField(\n max_length=2,\n choices=YearInSchool,\n default=YearInSchool.FRESHMAN,\n )\n\n def is_upperclass(self):\n return self.year_in_school in {\n self.YearInSchool.JUNIOR,\n self.YearInSchool.SENIOR,\n }\nDessa fungerar på liknande sätt som enum från Pythons standardbibliotek, men med vissa ändringar:
Enum-medlemsvärden är en tupel av argument som ska användas när den konkreta datatypen konstrueras. Django stöder att lägga till ett extra strängvärde i slutet av denna tuple som ska användas som det mänskliga läsbara namnet, eller label. label kan vara en lat översättningsbar sträng. I de flesta fall kommer alltså medlemsvärdet att vara en (värde, etikett) 2-tupel. Se nedan för ett exempel på underklassning av val med en mer komplex datatyp. Om en tupel inte tillhandahålls, eller om det sista objektet inte är en (lat) sträng, är label automatiskt genererad från medlemsnamnet.
En .label-egenskap läggs till på värden för att returnera det mänskligt läsbara namnet.
Ett antal anpassade egenskaper läggs till i uppräkningsklasserna - .choices, .labels, .values och .names - för att göra det lättare att komma åt listor över dessa separata delar av uppräkningen.
Användningen av enum.unique() är tvingande för att säkerställa att värden inte kan definieras flera gånger. Det är osannolikt att detta förväntas i val för ett fält.
Observera att användning av YearInSchool.SENIOR, YearInSchool['SENIOR'] eller YearInSchool('SR') för att komma åt eller slå upp enum-medlemmar fungerar som förväntat, liksom egenskaperna .name och .value på medlemmarna.
Om du inte behöver översätta de lättlästa namnen kan du låta dem härledas från medlemsnamnet (genom att ersätta understreck med mellanslag och använda titelfas):
\n>>> class Vehicle(models.TextChoices):\n... CAR = "C"\n... TRUCK = "T"\n... JET_SKI = "J"\n...\n>>> Vehicle.JET_SKI.label\n'Jet Ski'\nEftersom fallet där enumvärdena måste vara heltal är extremt vanligt, tillhandahåller Django en IntegerChoices-klass. Till exempel:
class Card(models.Model):\n class Suit(models.IntegerChoices):\n DIAMOND = 1\n SPADE = 2\n HEART = 3\n CLUB = 4\n\n suit = models.IntegerField(choices=Suit)\nDet är också möjligt att använda Enum Functional API med förbehållet att etiketter genereras automatiskt enligt ovan:
\n>>> MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")\n>>> MedalType.choices\n[('GOLD', 'Gold'), ('SILVER', 'Silver'), ('BRONZE', 'Bronze')]\n>>> Place = models.IntegerChoices("Place", "FIRST SECOND THIRD")\n>>> Place.choices\n[(1, 'First'), (2, 'Second'), (3, 'Third')]\nOm du behöver stöd för en annan konkret datatyp än int eller str kan du subklassa Choices och den nödvändiga konkreta datatypen, t.ex. date för användning med DateField:
class MoonLandings(datetime.date, models.Choices):\n APOLLO_11 = 1969, 7, 20, "Apollo 11 (Eagle)"\n APOLLO_12 = 1969, 11, 19, "Apollo 12 (Intrepid)"\n APOLLO_14 = 1971, 2, 5, "Apollo 14 (Antares)"\n APOLLO_15 = 1971, 7, 30, "Apollo 15 (Falcon)"\n APOLLO_16 = 1972, 4, 21, "Apollo 16 (Orion)"\n APOLLO_17 = 1972, 12, 11, "Apollo 17 (Challenger)"\nDet finns några ytterligare förbehåll att vara medveten om:
\nUppräkningstyper stöder inte namngivna grupper.
Eftersom en uppräkning med en konkret datatyp kräver att alla värden matchar typen, kan åsidosättande av blank label inte uppnås genom att skapa en medlem med värdet None. Istället ställer du in attributet __empty__ på klassen:
class Answer(models.IntegerChoices):\n NO = 0, _("No")\n YES = 1, _("Yes")\n\n __empty__ = _("(Unknown)")\ndb_kolumnLink to this heading#Namnet på den databaskolumn som ska användas för detta fält. Om detta inte anges kommer Django att använda fältets namn.
\nOm kolumnnamnet i din databas är ett reserverat SQL-ord eller innehåller tecken som inte är tillåtna i Python-variabelnamn - särskilt bindestrecket - är det OK. Django citerar kolumn- och tabellnamn bakom kulisserna.
\ndb_kommentarLink to this heading#Kommentaren till den databaskolumn som ska användas för detta fält. Det är användbart för att dokumentera fält för personer med direkt databasåtkomst som kanske inte tittar på din Django-kod. Till exempel:
\npub_date = models.DateTimeField(\n db_comment="Date and time when the article was published",\n)\ndb_defaultLink to this heading#Det databasberäknade standardvärdet för detta fält. Detta kan vara ett bokstavligt värde eller en databasfunktion, t.ex. Now:
created = models.DateTimeField(db_default=Now())\nMer komplexa uttryck kan användas, så länge de är uppbyggda av literaler och databasfunktioner:
\nmonth_due = models.DateField(\n db_default=TruncMonth(\n Now() + timedelta(days=90),\n output_field=models.DateField(),\n )\n)\nDatabasens standardvärden kan inte referera till andra fält eller modeller. Detta är till exempel ogiltigt:
\nend = models.IntegerField(db_default=F("start") + 50)\nOm både db_default och Field.default` är inställda kommer default att ha företräde när instanser skapas i Python-kod. db_default kommer fortfarande att vara inställt på databasnivå och kommer att användas när rader infogas utanför ORM eller när ett nytt fält läggs till i en migrering.
Om ett fält har ett db_default utan att ett default har angetts och inget värde har tilldelats fältet, returneras ett DatabaseDefault-objekt som fältvärde på osparade modellinstanser. Det faktiska värdet för fältet bestäms av databasen när modellinstansen sparas.
db_indexLink to this heading#Om True, skapas ett databasindex för detta fält.
db_tablespaceLink to this heading#Namnet på database tablespace som ska användas för fältets index, om fältet är indexerat. Standardvärdet är projektets DEFAULT_INDEX_TABLESPACE-inställning, om den är inställd, eller modellens db_tablespace, om det finns någon. Om backend inte stöder tablespaces för index, ignoreras detta alternativ.
standardLink to this heading#Standardvärdet för fältet. Detta kan vara ett värde eller ett anropsbart objekt. Om det är anropsbart kommer det att anropas varje gång ett nytt objekt skapas.
\nStandardvärdet kan inte vara ett föränderligt objekt (modellinstans, list, set, etc.), eftersom en referens till samma instans av det objektet skulle användas som standardvärde i alla nya modellinstanser. Istället kan du paketera det önskade standardvärdet i en callable. Om du till exempel vill ange en standard dict för JSONField, använd en funktion:
def contact_default():\n return {"email": "to1@example.com"}\n\n\ncontact_info = JSONField("ContactInfo", default=contact_default)\nlambda kan inte användas för fältalternativ som default eftersom de inte kan serialiseras av migreringar. Se den dokumentationen för andra varningar.
För fält som ForeignKey som mappar till modellinstanser bör standardvärdena vara värdet för det fält som de refererar till (pk om inte to_field är inställt) i stället för modellinstanser.
Standardvärdet används när nya modellinstanser skapas och inget värde har angetts för fältet. När fältet är en primärnyckel används standardvärdet även när fältet är inställt på None.
Standardvärdet kan också ställas in på databasnivå med Field.db_default.
Om False, kommer fältet inte att visas i admin eller någon annan ModelForm. Det kommer också att hoppas över under modellvalidering. Standard är True.
FelmeddelandenLink to this heading#Med argumentet error_messages kan du åsidosätta de standardmeddelanden som fältet kommer att ge upphov till. Skicka in en ordbok med nycklar som matchar de felmeddelanden som du vill åsidosätta.
Felmeddelanden inkluderar null, blank, invalid, invalid_choice, unique och unique_for_date. Ytterligare nycklar för felmeddelanden anges för varje fält i avsnittet ”Fälttyper” nedan.
Dessa felmeddelanden sprids ofta inte till formulär. Se betraktelser-om-modell-felmeddelanden.
\nhjälp_textLink to this heading#Extra ”hjälp”-text som ska visas med formulärwidgeten. Det är användbart för dokumentation även om ditt fält inte används i ett formulär.
\nObservera att detta värde inte är HTML-escaped i automatiskt genererade formulär. Detta gör att du kan inkludera HTML i help_text om du så önskar. Till exempel:
help_text = "Please use the following format: <em>YYYY-MM-DD</em>."\nAlternativt kan du använda vanlig text och django.utils.html.escape() för att undkomma alla HTML-specialtecken. Se till att du undandrar all hjälptext som kan komma från icke betrodda användare för att undvika en cross-site scripting-attack.
primär_nyckelLink to this heading#Om True, är detta fält primärnyckel för modellen.
Om du inte anger primary_key=True för något fält i din modell och inte har definierat en sammansatt primärnyckel, kommer Django automatiskt att lägga till ett fält för att hålla primärnyckeln. Så du behöver inte ställa in primary_key=True på något av dina fält om du inte vill åsidosätta standardbeteendet för primärnyckeln. Typen av automatiskt skapade primärnyckelfält kan anges per app i AppConfig.default_auto_field eller globalt i inställningen DEFAULT_AUTO_FIELD. För mer information, se Automatiska primärnyckelfält.
primary_key=True innebär null=False och unique=True. Endast ett fält per modell kan ange primary_key=True. Sammansatta primärnycklar måste definieras med hjälp av CompositePrimaryKey i stället för att sätta denna flagga till True för alla fält för att bibehålla denna invariant.
Fältet primary key är skrivskyddat. Om du ändrar värdet på primärnyckeln i ett befintligt objekt och sedan sparar det, skapas ett nytt objekt vid sidan av det gamla.
\nPrimärnyckelfältet sätts till None när deleting ett objekt.
uniqueLink to this heading#Om True måste detta fält vara unikt i hela tabellen.
Detta verkställs på databasnivå och genom modellvalidering. Om du försöker spara en modell med ett duplicerat värde i ett unique-fält, kommer ett django.db.IntegrityError att skapas av modellens save()-metod.
Detta alternativ är giltigt för alla fälttyper utom ManyToManyField och OneToOneField.
Observera att när unique är True behöver du inte ange db_index, eftersom unique innebär att ett index skapas.
unique_for_dateLink to this heading#Ange detta till namnet på en DateField eller DateTimeField för att kräva att detta fält är unikt för datumfältets värde.
Om du till exempel har ett fält title som har unique_for_date="pub_date", så skulle Django inte tillåta att två poster med samma title och pub_date registreras.
Observera att om du ställer in detta så att det pekar på en DateTimeField, kommer endast datumdelen av fältet att beaktas. Dessutom, när USE_TZ är True, kommer kontrollen att utföras i current time zone vid den tidpunkt då objektet sparas.
Detta verkställs av Model.validate_unique() under modellvalidering men inte på databasnivå. Om någon unique_for_date-restriktion involverar fält som inte är en del av en ModelForm (till exempel om ett av fälten är listat i exclude eller har editable=False), kommer Model.validate_unique() att hoppa över valideringen för den specifika restriktionen.
unika_för_månadLink to this heading#Som unique_for_date, men kräver att fältet är unikt med avseende på månaden.
unique_for_yearLink to this heading#Som unique_for_date och unique_for_month.
verbose_namnLink to this heading#Ett mänskligt läsbart namn för fältet. Om verbose-namnet inte anges kommer Django automatiskt att skapa det med hjälp av fältets attributnamn och konvertera understreck till mellanslag. Se Verbose field names.
\nvaliderareLink to this heading#En lista över validerare som ska köras för detta fält. Se validators dokumentation för mer information.
\nAutoFieldLink to this heading#En IntegerField som automatiskt ökar i enlighet med tillgängliga ID:n. Du behöver vanligtvis inte använda detta direkt; ett primärnyckelfält kommer automatiskt att läggas till i din modell om du inte anger något annat. Se Automatiska primärnyckelfält.
BigAutoFieldLink to this heading#Ett 64-bitars heltal, ungefär som en AutoField förutom att det garanterat passar siffror från 1 till 9223372036854775807.
BigIntegerFieldLink to this heading#Ett 64-bitars heltal, ungefär som ett IntegerField förutom att det garanterat passar siffror från -9223372036854775808 till 9223372036854775807. Standardformulärwidgeten för detta fält är en NumberInput.
BinaryFieldLink to this heading#Ett fält för att lagra binära rådata. Det kan tilldelas bytes, bytearray eller memoryview.
Som standard ställer BinaryField in editable till False, i vilket fall den inte kan inkluderas i en ModelForm.
Valfritt. Den maximala längden (i byte) på fältet. Den maximala längden verkställs i Djangos validering med hjälp av MaxLengthValidator.
BooleanFieldLink to this heading#Ett sant/falskt fält.
\nStandardformulärwidgeten för detta fält är CheckboxInput, eller NullBooleanSelect om null=True.
Standardvärdet för BooleanField är None när Field.default inte är definierat.
SammansattPrimärnyckelLink to this heading#Ett virtuellt fält som används för att definiera en sammansatt primärnyckel.
\nDetta fält måste definieras som modellens pk-attribut. Om det finns kommer Django att skapa den underliggande modelltabellen med en sammansatt primärnyckel.
Argumentet *field_names är en lista med positionella fältnamn som utgör primärnyckeln.
Se Sammansatta primärnycklar för mer information.
\nCharFieldLink to this heading#Ett strängfält, för små till stora strängar.
\nFör stora mängder text, använd TextField.
Standardformulärwidgeten för detta fält är en TextInput.
CharField har följande extra argument:
Den maximala längden (i tecken) på fältet. max_length verkställs på databasnivå och i Djangos validering med hjälp av MaxLengthValidator. Det krävs för alla databasbackends som ingår i Django utom PostgreSQL och SQLite, som stöder obegränsade VARCHAR-kolumner.
Valfritt. Databasens kollationsnamn för fältet.
\n\n\nDateFieldLink to this heading#Ett datum, representerat i Python av en datetime.date-instans. Har några extra, valfria argument:
Ställ automatiskt in fältet på now varje gång objektet sparas. Användbart för tidsstämplar för ”senast ändrad”. Observera att det aktuella datumet alltid används; det är inte bara ett standardvärde som du kan åsidosätta.
\nFältet uppdateras endast automatiskt när du anropar Model.save(). Fältet uppdateras inte när du gör uppdateringar av andra fält på andra sätt, t.ex. QuerySet.update(), men du kan ange ett anpassat värde för fältet i en sådan uppdatering.
Ställ automatiskt in fältet på now när objektet skapas för första gången. Användbart för skapande av tidsstämplar. Observera att det aktuella datumet alltid används; det är inte bara ett standardvärde som du kan åsidosätta. Så även om du anger ett värde för det här fältet när du skapar objektet kommer det att ignoreras. Om du vill kunna ändra det här fältet anger du följande i stället för auto_now_add=True:
För DateField: default=date.today - från datetime.date.today()
För DateTimeField: default=timezone.now - från django.utils.timezone.now()
Standardformulärwidgeten för detta fält är en DateInput. Administratören lägger till en JavaScript-kalender och en genväg för ”Today”. Inkluderar ytterligare en nyckel för felmeddelandet invalid_date.
Alternativen auto_now_add, auto_now och default är ömsesidigt uteslutande. Varje kombination av dessa alternativ kommer att resultera i ett fel.
DatumTimeFieldLink to this heading#Ett datum och en tid, representerade i Python av en datetime.datetime-instans. Tar samma extra argument som DateField.
Standardformulärwidgeten för detta fält är en enda DateTimeInput. Administratören använder två separata TextInput-widgetar med JavaScript-genvägar.
DecimalFieldLink to this heading#Ett decimaltal med fast precision, representerat i Python av en Decimal-instans. Den validerar indata med hjälp av DecimalValidator.
Har följande krävda argument:
\nDet maximala antalet siffror som tillåts i talet. Observera att detta tal måste vara större än eller lika med decimal_places.
Antalet decimaler som ska lagras med talet.
\nOm du t.ex. vill lagra siffror upp till 999,99 med en upplösning på 2 decimaler använder du:
\nmodels.DecimalField(..., max_digits=5, decimal_places=2)\nOch för att lagra tal upp till cirka en miljard med en upplösning på 10 decimaler:
\nmodels.DecimalField(..., max_digits=19, decimal_places=10)\nStandardformulärwidgeten för detta fält är en NumberInput när localize är False eller annars TextInput.
DurationFieldLink to this heading#Ett fält för lagring av tidsperioder - modellerat i Python av timedelta. När den används på PostgreSQL är datatypen som används ett intervall och på Oracle är datatypen INTERVAL DAY (9) TO SECOND (6) ``. Annars används en ``bigint av mikrosekunder.
EmailFieldLink to this heading#En CharField som kontrollerar att värdet är en giltig e-postadress med hjälp av EmailValidator.
FileFieldLink to this heading#Ett fält för filuppladdning.
\n\nHar följande valfria argument:
\nDetta attribut ger ett sätt att ställa in uppladdningskatalogen och filnamnet, och kan ställas in på två sätt. I båda fallen skickas värdet till metoden Storage.save().
Om du anger ett strängvärde eller en Path kan det innehålla strftime()-formatering, som ersätts med datumet/tiden för filuppladdningen (så att uppladdade filer inte fyller upp den angivna katalogen). Till exempel:
class MyModel(models.Model):\n # file will be uploaded to MEDIA_ROOT/uploads\n upload = models.FileField(upload_to="uploads/")\n # or...\n # file will be saved to MEDIA_ROOT/uploads/2015/01/30\n upload = models.FileField(upload_to="uploads/%Y/%m/%d/")\nOm du använder standard FileSystemStorage, kommer strängvärdet att läggas till din MEDIA_ROOT sökväg för att bilda platsen på det lokala filsystemet där uppladdade filer kommer att lagras. Om du använder en annan lagring, kontrollera dokumentationen för den lagringen för att se hur den hanterar upload_to.
upload_to kan också vara en anropbar funktion, t.ex. en funktion. Denna kommer att anropas för att erhålla uppladdningssökvägen, inklusive filnamnet. Denna anropbara funktion måste acceptera två argument och returnera en sökväg i Unix-stil (med snedstreck) som ska skickas vidare till lagringssystemet. De två argumenten är:
Argument | \nBeskrivning | \n
|---|---|
| \nEn instans av modellen där I de flesta fall har det här objektet inte sparats i databasen ännu, så om det använder standardinställningen | \n
| \nDet filnamn som ursprungligen gavs till filen. Detta kan eller kan inte tas med i beräkningen när den slutliga destinationssökvägen bestäms. | \n
Till exempel:
\ndef user_directory_path(instance, filename):\n # file will be uploaded to MEDIA_ROOT/user_<id>/<filename>\n return "user_{0}/{1}".format(instance.user.id, filename)\n\n\nclass MyModel(models.Model):\n upload = models.FileField(upload_to=user_directory_path)\nEtt lagringsobjekt eller en anropsbar funktion som returnerar ett lagringsobjekt. Detta hanterar lagring och hämtning av dina filer. Se Hantera filer för mer information om hur du tillhandahåller detta objekt.
\nStandardformulärwidgeten för detta fält är en ClearableFileInput.
Att använda en FileField eller en ImageField (se nedan) i en modell kräver några steg:
I din inställningsfil måste du definiera MEDIA_ROOT som den fullständiga sökvägen till en katalog där du vill att Django ska lagra uppladdade filer. (Av prestandaskäl lagras inte dessa filer i databasen.) Definiera MEDIA_URL som den publika URL:en för den katalogen. Se till att den här katalogen är skrivbar av webbserverns användarkonto.
Lägg till FileField eller ImageField i din modell och definiera alternativet upload_to för att ange en underkatalog i MEDIA_ROOT som ska användas för uppladdade filer.
Allt som kommer att lagras i din databas är en sökväg till filen (i förhållande till MEDIA_ROOT). Du kommer troligen att vilja använda det praktiska attributet url som tillhandahålls av Django. Om din ImageField till exempel heter mug_shot kan du få den absoluta sökvägen till din bild i en mall med {{ object.mug_shot.url }}.
Anta till exempel att din MEDIA_ROOT är inställd på '/home/media' och upload_to är inställd på 'photos/%Y/%m/%d'. Delen '%Y/%m/%d' i upload_to är strftime()-formatering; '%Y' är det fyrsiffriga året, '%m' är den tvåsiffriga månaden och '%d' är den tvåsiffriga dagen. Om du laddar upp en fil den 15 januari 2007 kommer den att sparas i katalogen /home/media/photos/2007/01/15.
Om du vill hämta den uppladdade filens filnamn på disken eller filens storlek kan du använda attributen name respektive size; för mer information om tillgängliga attribut och metoder, se klassreferensen File och ämnesguiden Hantera filer.
Den uppladdade filens relativa URL kan erhållas med hjälp av attributet url. Internt anropar detta url()-metoden för den underliggande Storage-klassen.
Observera att när du hanterar uppladdade filer bör du vara mycket uppmärksam på var du laddar upp dem och vilken typ av filer de är, för att undvika säkerhetshål. Validera alla uppladdade filer så att du är säker på att filerna är vad du tror att de är. Om du till exempel blint låter någon ladda upp filer, utan validering, till en katalog som ligger i din webbservers dokumentrot, kan någon ladda upp ett CGI- eller PHP-skript och köra det skriptet genom att besöka dess URL på din webbplats. Tillåt inte det.
\nObservera också att även en uppladdad HTML-fil, eftersom den kan köras av webbläsaren (men inte av servern), kan utgöra säkerhetshot som motsvarar XSS- eller CSRF-attacker.
\nFileField-instanser skapas i din databas som varchar-kolumner med en maximal standardlängd på 100 tecken. Precis som för andra fält kan du ändra den maximala längden med argumentet max_length.
FileField och FieldFileLink to this heading#När du öppnar en FileField på en modell får du en instans av FieldFile som en proxy för åtkomst till den underliggande filen.
API:et för FieldFile speglar det för File, med en viktig skillnad: *Objektet som klassen omsluter är inte nödvändigtvis en omslutning kring Pythons inbyggda filobjekt * Istället är det en omslutning kring resultatet av Storage.open()-metoden, som kan vara ett File-objekt, eller det kan vara en anpassad lagrings implementering av File API.
Utöver API:et som ärvs från File, såsom read() och write(), innehåller FieldFile flera metoder som kan användas för att interagera med den underliggande filen:
Namnet på filen inklusive den relativa sökvägen från roten till Storage för den associerade FileField.
En skrivskyddad egenskap för att komma åt filens lokala filsystemssökväg genom att anropa path()-metoden i den underliggande Storage-klassen.
Resultatet av den underliggande Storage.size()-metoden.
En skrivskyddad egenskap för att komma åt filens relativa URL genom att anropa url()-metoden i den underliggande Storage-klassen.
Öppnar eller återöppnar filen som är associerad med denna instans i angivet mode. Till skillnad från Pythons standardmetod open() returnerar den inte en filbeskrivare.
Eftersom den underliggande filen öppnas implicit vid åtkomst till den, kan det vara onödigt att anropa denna metod förutom för att återställa pekaren till den underliggande filen eller för att ändra mode.
Uppträder som Pythons standardmetod file.close() och stänger den fil som är kopplad till denna instans.
Den här metoden tar ett filnamn och filinnehåll och skickar dem till lagringsklassen för fältet och associerar sedan den lagrade filen med modellfältet. Om du manuellt vill associera fildata med FileField-instanser i din modell, används metoden save() för att bevara fildata.
Tar två obligatoriska argument: name som är namnet på filen och content som är ett objekt som innehåller filens innehåll. Det valfria argumentet save styr om modellinstansen sparas eller inte efter att filen som är associerad med detta fält har ändrats. Standardvärdet är True.
Observera att argumentet content ska vara en instans av django.core.files.File, inte Pythons inbyggda filobjekt. Du kan konstruera en File från ett befintligt Python-filobjekt så här:
from django.core.files import File\n\n# Open an existing file using Python's built-in open()\nf = open("/path/to/hello.world")\nmyfile = File(f)\nEller så kan du konstruera en från en Python-sträng så här:
\nfrom django.core.files.base import ContentFile\n\nmyfile = ContentFile("hello world")\nFör mer information, se Hantera filer.
\nRaderar filen som är kopplad till denna instans och rensar alla attribut på fältet. Observera: Den här metoden stänger filen om den råkar vara öppen när delete() anropas.
Det valfria argumentet save styr om modellinstansen sparas eller inte efter att filen som är associerad med detta fält har tagits bort. Standardvärdet är True.
Observera att när en modell tas bort tas inte relaterade filer bort. Om du behöver rensa bort föräldralösa filer måste du hantera det själv (t.ex. med ett anpassat hanteringskommando som kan köras manuellt eller schemaläggas för att köras regelbundet via t.ex. cron).
\nFilePathFieldLink to this heading#En CharField vars valmöjligheter är begränsade till filnamnen i en viss katalog på filsystemet. Har några specialargument, varav det första är obligatoriskt:
Obligatorisk. Den absoluta filsystemssökvägen till en katalog från vilken denna FilePathField ska hämta sina val. Exempel: "/home/images".
path kan också vara en anropsbar funktion, t.ex. en funktion för att dynamiskt ställa in sökvägen vid körning. Exempel:
import os\nfrom django.conf import settings\nfrom django.db import models\n\n\ndef images_path():\n return os.path.join(settings.LOCAL_FILE_DIR, "images")\n\n\nclass MyModel(models.Model):\n file = models.FilePathField(path=images_path)\nValfritt. Ett reguljärt uttryck, som en sträng, som FilePathField kommer att använda för att filtrera filnamn. Observera att regex kommer att tillämpas på basfilnamnet, inte på hela sökvägen. Exempel: "foo.*\\.txt$", vilket matchar en fil som heter foo23.txt men inte bar.txt eller foo23.png.
Valfritt. Antingen True eller False. Standard är False. Anger om alla underkataloger till path ska inkluderas
Valfritt. Antingen True eller False. Standard är True. Anger om filer på den angivna platsen ska inkluderas. Antingen detta eller allow_folders måste vara True.
Valfritt. Antingen True eller False. Standard är False. Anger om mappar på den angivna platsen ska inkluderas. Antingen detta eller allow_files måste vara True.
Det enda potentiella problemet är att match gäller för det grundläggande filnamnet, inte den fullständiga sökvägen. Så i det här exemplet:
FilePathField(path="/home/images", match="foo.*", recursive=True)\n…kommer att matcha /home/images/foo.png men inte /home/images/foo/bar.png eftersom match gäller för basfilnamnet (foo.png och bar.png).
FilePathField-instanser skapas i din databas som varchar-kolumner med en maximal standardlängd på 100 tecken. Precis som för andra fält kan du ändra den maximala längden med hjälp av argumentet max_length.
FloatFieldLink to this heading#Ett flyttal som i Python representeras av en float-instans.
Standardformulärwidgeten för detta fält är en NumberInput när localize är False eller annars TextInput.
GeneratedFieldLink to this heading#Ett fält som alltid beräknas baserat på andra fält i modellen. Detta fält hanteras och uppdateras av databasen själv. Använder SQL-syntaxen GENERATED ALWAYS.
Det finns två typer av genererade kolumner: lagrade och virtuella. En lagrad genererad kolumn beräknas när den skrivs (infogas eller uppdateras) och tar upp lagringsutrymme som om det vore en vanlig kolumn. En virtuell genererad kolumn upptar ingen lagringsplats och beräknas när den läses. En virtuell genererad kolumn liknar alltså en vy och en lagrad genererad kolumn liknar en materialiserad vy.
\nEtt Expression som används av databasen för att automatiskt ställa in fältvärdet varje gång modellen ändras.
Uttrycken ska vara deterministiska och endast referera till fält inom modellen (i samma databastabell). Genererade fält kan inte referera till andra genererade fält. Databasbackends kan införa ytterligare begränsningar.
\nEn modellfältsinstans för att definiera fältets datatyp.
\nBestämmer om databaskolumnen ska ta upp lagringsutrymme som om den vore en riktig kolumn. Om False, fungerar kolumnen som en virtuell kolumn och tar inte upp lagringsutrymme i databasen.
PostgreSQL stöder endast kvarvarande kolumner. Oracle stöder endast virtuella kolumner.
\nGenericIPAddressFieldLink to this heading#En IPv4- eller IPv6-adress i strängformat (t.ex. 192.0.2.30 eller 2a02:42fe::4). Standardformulärwidgeten för detta fält är en TextInput.
Normaliseringen av IPv6-adresser följer RFC 4291 Section 2.2 avsnitt 2.2, inklusive användning av det IPv4-format som föreslås i punkt 3 i det avsnittet, som ::ffff:192.0.2.0. Till exempel: skulle 2001:0::0:01 normaliseras till 2001::1, och ::ffff:0a0a:0a0a till ::ffff:10.10.10.10. Alla tecken konverteras till gemener.
Begränsar giltiga indata till det angivna protokollet. Accepterade värden är 'both' (standard), 'IPv4' eller 'IPv6'. Matchningen är okänslig för skiftlägesskillnader.
Packar upp IPv4-mappade adresser som ::ffff:192.0.2.1. Om detta alternativ är aktiverat kommer den adressen att packas upp till 192.0.2.1. Standard är inaktiverat. Kan endast användas när protocol är inställt på 'both'.
Om du tillåter tomma värden måste du tillåta null-värden eftersom tomma värden lagras som null.
\nImageFieldLink to this heading#Ärver alla attribut och metoder från FileField, men validerar också att det uppladdade objektet är en giltig bild.
Förutom de specialattribut som finns för FileField har en ImageField även attributen height och width.
För att göra det lättare att ställa frågor om dessa attribut har ImageField följande valfria argument:
Namn på ett modellfält som automatiskt fylls i med bildens höjd varje gång ett bildobjekt ställs in.
\nNamn på ett modellfält som automatiskt fylls i med bildens bredd varje gång ett bildobjekt ställs in.
\nKräver biblioteket pillow.
\nImageField-instanser skapas i din databas som varchar-kolumner med en maximal standardlängd på 100 tecken. Precis som för andra fält kan du ändra den maximala längden med argumentet max_length.
Standardformulärwidgeten för detta fält är en ClearableFileInput.
IntegerFieldLink to this heading#Ett heltal. Värden är endast tillåtna mellan vissa (databasberoende) punkter. Värden från -2147483648 till 2147483647 är kompatibla i alla databaser som stöds av Django.
Den använder MinValueValidator och MaxValueValidator för att validera inmatningen baserat på de värden som standarddatabasen stöder.
Standardformulärwidgeten för detta fält är en NumberInput när localize är False eller annars TextInput.
JSONFieldLink to this heading#Ett fält för lagring av JSON-kodade data. I Python representeras data i Pythons ursprungliga format: ordböcker, listor, strängar, siffror, booleaner och None.
JSONField stöds på MariaDB, MySQL, Oracle, PostgreSQL och SQLite (med JSON1-tillägget aktiverat).
En valfri json.JSONEncoder-underklass för att serialisera datatyper som inte stöds av standard JSON serializer (t.ex. datetime.datetime eller UUID). Du kan till exempel använda klassen DjangoJSONEncoder.
Standardvärdet är json.JSONEncoder.
En valfri json.JSONDecoder-underklass för att deserialisera värdet som hämtats från databasen. Värdet kommer att vara i det format som valts av den anpassade kodaren (oftast en sträng). Din deserialisering kan behöva ta hänsyn till det faktum att du inte kan vara säker på indatatypen. Du riskerar till exempel att returnera en datetime som faktiskt var en sträng som bara råkade vara i samma format som valts för datetime.
Standardvärdet är json.JSONDecoder.
För att fråga JSONField i databasen, se Fråga om JSONField.
PositivBigIntegerFieldLink to this heading#Som en PositiveIntegerField, men tillåter bara värden under en viss (databasberoende) punkt. Värden från 0 till 9223372036854775807 är kompatibla i alla databaser som stöds av Django.
PositivIntegerFieldLink to this heading#Som en IntegerField, men måste vara antingen positiv eller noll (0). Värden är endast tillåtna under en viss (databasberoende) punkt. Värden från 0 till 2147483647 är kompatibla i alla databaser som stöds av Django. Värdet 0 accepteras av bakåtkompatibilitetsskäl.
Positiv liten heltalsfältLink to this heading#Som en PositiveIntegerField, men tillåter bara värden under en viss (databasberoende) punkt. Värden från 0 till 32767 är kompatibla i alla databaser som stöds av Django.
SlugFieldLink to this heading#Slug är en term för tidningar. En slug är en kort etikett för något, som bara innehåller bokstäver, siffror, understrykningar eller bindestreck. De används i allmänhet i webbadresser.
\nPrecis som en CharField kan du ange max_length (läs även anmärkningen om databasportabilitet och max_length i det avsnittet). Om max_length inte anges kommer Django att använda en standardlängd på 50.
Innebär att Field.db_index sätts till True.
Det är ofta användbart att automatiskt fylla i en SlugField baserat på värdet av något annat värde. Du kan göra detta automatiskt i admin med prepopulated_fields.
Den använder validate_slug eller validate_unicode_slug för validering.
Om True, accepterar fältet Unicode-bokstäver utöver ASCII-bokstäver. Standardvärdet är False.
SmallAutoFieldLink to this heading#Som en AutoField, men tillåter bara värden under en viss (databasberoende) gräns. Värden från 1 till 32767 är kompatibla i alla databaser som stöds av Django.
LitenIntegerFieldLink to this heading#Som en IntegerField, men tillåter bara värden under en viss (databasberoende) punkt. Värden från -32768 till 32767 är kompatibla i alla databaser som stöds av Django.
TextfältLink to this heading#Ett stort textfält. Standardformulärwidgeten för detta fält är en Textarea.
Om du anger ett max_length-attribut kommer det att återspeglas i Textarea-widgeten i det autogenererade formulärfältet. Det verkställs dock inte på modell- eller databasnivå. Använd en CharField för det.
Valfritt. Databasens kollationsnamn för fältet.
\n\n\nTimeFieldLink to this heading#En tid, representerad i Python av en datetime.time-instans. Accepterar samma autopopuleringsalternativ som DateField.
Standardformulärwidgeten för detta fält är en TimeInput. Administratören lägger till några JavaScript-genvägar.
URL-fältLink to this heading#En CharField för en URL, validerad av URLValidator.
Standardformulärwidgeten för det här fältet är en URLInput.
Som alla CharField-subklasser tar URLField det valfria argumentet max_length. Om du inte anger max_length används standardvärdet 200.
UUIDFieldLink to this heading#Ett fält för lagring av universellt unika identifierare. Använder Pythons UUID klass. När det används på PostgreSQL och MariaDB 10.7+ lagras detta i en uuid datatyp, annars i en ``char (32) ``.
Universellt unika identifierare är ett bra alternativ till AutoField för primary_key. Databasen kommer inte att generera UUID åt dig, så det rekommenderas att du använder default:
import uuid\nfrom django.db import models\n\n\nclass MyUUIDModel(models.Model):\n id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)\n # other fields\nObservera att en callable (med parenteserna utelämnade) skickas till default, inte en instans av UUID.
Field är en abstrakt klass som representerar en kolumn i en databastabell. Django använder fält för att skapa databastabellen (db_type()), för att mappa Python-typer till databasen (get_prep_value()) och vice versa (from_db_value()).
Ett fält är således en grundläggande del i olika Django API:er, i synnerhet models och querysets.
I modeller är ett fält instansierat som ett klassattribut och representerar en viss tabellkolumn, se Modeller. Det har attribut som null och unique, och metoder som Django använder för att mappa fältvärdet till databasspecifika värden.
En Field är en underklass av RegisterLookupMixin och därmed kan både Transform och Lookup` registreras på den för att användas i QuerySet (t.ex. field_name__exact="foo"). Alla inbyggda lookups är registrerade som standard.
Alla Djangos inbyggda fält, till exempel CharField, är särskilda implementeringar av Field. Om du behöver ett anpassat fält kan du antingen subklassa något av de inbyggda fälten eller skriva ett Field från början. I båda fallen, se Så här skapar du anpassade modellfält.
En utförlig beskrivning av fältet, t.ex. för programmet django.contrib.admindocs.
Beskrivningen kan vara av formen:
\ndescription = _("String (up to %(max_length)s)")\ndär argumenten interpoleras från fältets __dict__.
En klass som implementerar descriptor protocol som instansieras och tilldelas attributet för modellinstansen. Konstruktören måste acceptera ett enda argument, Field-instansen. Åsidosättande av detta klassattribut gör det möjligt att anpassa get- och set-beteendet.
För att mappa en Field till en databasspecifik typ, exponerar Django flera metoder:
Returnerar en sträng som namnger detta fält för backend-specifika ändamål. Som standard returneras klassnamnet.
\nSe Emulering av inbyggda fälttyper för användning i anpassade fält.
\nReturnerar databaskolumnens datatyp för Field, med hänsyn tagen till connection.
Se Anpassade databastyper för användning i anpassade fält.
\nReturnerar databasens kolumndatatyp för fält som ForeignKey och OneToOneField som pekar på Field, med hänsyn tagen till connection.
Se Anpassade databastyper för användning i anpassade fält.
\nDet finns tre huvudsakliga situationer där Django behöver interagera med databasens backend och fält:
\nnär den frågar databasen (Python-värde -> databasens backend-värde)
när den laddar data från databasen (databasens backend-värde -> Python-värde)
när den sparar i databasen (Python-värde -> databasens backend-värde)
Vid frågor används get_db_prep_value() och get_prep_value():
value är det aktuella värdet för modellens attribut och metoden ska returnera data i ett format som har förberetts för att användas som en parameter i en fråga.
Se Konvertera Python-objekt till frågevärden för användning.
\nKonverterar value till ett backend-specifikt värde. Som standard returnerar den value om prepared=True och get_prep_value() om är False.
Se Konvertering av frågevärden till databasvärden för användning.
\nVid laddning av data används from_db_value():
Konverterar ett värde som returneras av databasen till ett Python-objekt. Det är det omvända av get_prep_value().
Den här metoden används inte för de flesta inbyggda fält eftersom databasens backend redan returnerar rätt Python-typ, eller så gör backend själv konverteringen.
\nuttryck är detsamma som själv.
Se Konvertera värden till Python-objekt för användning.
\n\nNär du sparar används pre_save() och get_db_prep_save():
Samma som get_db_prep_value(), men anropas när fältvärdet måste sparas till databasen. Som standard returneras get_db_prep_value().
Metod som anropas före get_db_prep_save() för att förbereda värdet innan det sparas (t.ex. för DateField.auto_now).
model_instance är den instans som detta fält tillhör och add är om instansen sparas i databasen för första gången.
Det bör returnera värdet på lämpligt attribut från model_instance för detta fält. Attributnamnet finns i self.attname (detta ställs in av Field).
Se Förbehandling av värden före lagring för användning.
\nFält får ofta sina värden som en annan typ, antingen från serialisering eller från formulär.
\nKonverterar värdet till det korrekta Python-objektet. Det fungerar som det omvända av value_to_string(), och anropas också i clean().
Se Konvertera värden till Python-objekt för användning.
\nFörutom att spara i databasen måste fältet också veta hur det ska serialisera sitt värde:
\nReturnerar fältets värde för den angivna modellinstansen.
\nDenna metod används ofta av value_to_string().
Konverterar obj till en sträng. Används för att serialisera fältets värde.
Se Konvertering av fältdata för serialisering för användning.
\nNär man använder model forms, måste Field veta vilket formulärfält den ska representeras av:
Returnerar standard django.forms.Field för detta fält för ModelForm.
Om formfield() åsidosätts för att returnera None, utesluts detta fält från ModelForm.
Som standard, om både form_class och choices_form_class är None, används CharField. Om fältet har choices och choices_form_class inte är specificerat, används TypedChoiceField.
Se specificerande-form-fält-för-modell-fält för användning.
\nReturnerar en 4-tupel med tillräckligt med information för att återskapa fältet:
\nNamnet på fältet i modellen.
Importsökvägen för fältet (t.ex. "django.db.models.IntegerField"). Detta bör vara den mest portabla versionen, så mindre specifik kan vara bättre.
En lista med positionella argument.
En dikt av nyckelordsargument.
Denna metod måste läggas till fält före 1.7 för att migrera dess data med hjälp av Migreringar.
\nField implementerar lookup registration API. API:et kan användas för att anpassa vilka uppslagsord som är tillgängliga för en fältklass och dess instanser, och hur uppslagsord hämtas från ett fält.
Varje Field-instans innehåller flera attribut som gör det möjligt att introspektera dess beteende. Använd dessa attribut istället för isinstance-kontroller när du behöver skriva kod som är beroende av ett fälts funktionalitet. Dessa attribut kan användas tillsammans med Model._meta API för att begränsa en sökning efter specifika fälttyper. Anpassade modellfält bör implementera dessa flaggor.
Boolesk flagga som anger om fältet skapades automatiskt, t.ex. OneToOneField som används vid modellarv.
Boolesk flagga som anger om fältet har en databaskolumn associerad med sig.
\nBoolesk flagga som anger om ett fält är dolt och inte ska returneras av Options.get_fields() som standard. Ett exempel är det omvända fältet för en ForeignKey med ett related_name som börjar med '+'.
Boolesk flagga som anger om ett fält innehåller referenser till en eller flera andra modeller för dess funktionalitet (t.ex. ForeignKey, ManyToManyField, OneToOneField, etc.).
Returnerar den modell som fältet är definierat för. Om ett fält definieras på en superklass av en modell, kommer model att hänvisa till superklassen, inte klassen för instansen.
Dessa attribut används för att fråga efter kardinalitet och andra detaljer i en relation. Dessa attribut finns på alla fält, men de har endast booleska värden (i stället för None) om fältet är en relationstyp (Field.is_relation=True).
Boolesk flagga som är True om fältet har en many-to-many-relation; False annars. Det enda fältet som ingår i Django där detta är True är ManyToManyField.
Boolesk flagga som är True om fältet har en många-till-en-relation, t.ex. en ForeignKey; annars False.
Boolesk flagga som är True om fältet har en en-till-många-relation, t.ex. en GenericRelation eller motsatsen till en ForeignKey; annars False.
Boolesk flagga som är True om fältet har en en-till-en-relation, t.ex. ett OneToOneField; annars False.
Pekar på den modell som fältet hänför sig till. Till exempel: Author i ForeignKey(Author, on_delete=models.CASCADE). Den related_model för en GenericForeignKey är alltid None.