En modell är den enda, definitiva källan till information om dina data. Den innehåller de viktigaste fälten och beteendena för de data som du lagrar. I allmänhet mappar varje modell till en enda databastabell.
\nGrunderna:
\nVarje modell är en Python-klass som är underklass till django.db.models.Model.
Varje attribut i modellen representerar ett fält i databasen.
Med allt detta ger Django dig ett automatiskt genererat API för databasåtkomst; se Göra förfrågningar.
Denna exempelmodell definierar en Person, som har ett förnamn och efternamn:
from django.db import models\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=30)\n last_name = models.CharField(max_length=30)\nförnamn och efternamn är fält i modellen. Varje fält anges som ett klassattribut och varje attribut mappar till en databaskolumn.
Modellen Person ovan skulle skapa en databastabell så här:
CREATE TABLE myapp_person (\n "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n "first_name" varchar(30) NOT NULL,\n "last_name" varchar(30) NOT NULL\n);\nNågra tekniska anmärkningar:
\nTabellens namn, myapp_person, härleds automatiskt från vissa modellmetadata men kan åsidosättas. Se Tabellnamn för mer information.
Ett id-fält läggs till automatiskt, men detta beteende kan åsidosättas. Se Automatiska primärnyckelfält.
SQL-filen CREATE TABLE i det här exemplet är formaterad med PostgreSQL-syntax, men det är värt att notera att Django använder SQL skräddarsydd för databasens backend som anges i din settings-fil.
När du har definierat dina modeller måste du tala om för Django att du ska använda dessa modeller. Gör detta genom att redigera din inställningsfil och ändra inställningen INSTALLED_APPS för att lägga till namnet på den modul som innehåller dina models.py.
Om modellerna för din applikation till exempel finns i modulen myapp.models (den paketstruktur som skapas för en applikation av skriptet manage.py startapp), bör INSTALLED_APPS delvis lyda:
INSTALLED_APPS = [\n # ...\n "myapp",\n # ...\n]\nNär du lägger till nya appar i INSTALLED_APPS ska du se till att köra manage.py migrate, och eventuellt göra migreringar för dem först med manage.py makemigrations.
Den viktigaste delen av en modell - och den enda obligatoriska delen av en modell - är listan över databasfält som den definierar. Fält specificeras av klassattribut. Var försiktig så att du inte väljer fältnamn som står i konflikt med models API som clean, save eller delete.
Exempel:
\nfrom django.db import models\n\n\nclass Musician(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n instrument = models.CharField(max_length=100)\n\n\nclass Album(models.Model):\n artist = models.ForeignKey(Musician, on_delete=models.CASCADE)\n name = models.CharField(max_length=100)\n release_date = models.DateField()\n num_stars = models.IntegerField()\nVarje fält i din modell bör vara en instans av den lämpliga Field-klassen. Django använder fältklasstyperna för att bestämma några saker:
Kolumntypen, som talar om för databasen vilken typ av data som ska lagras (t.ex. INTEGER, VARCHAR, TEXT).
Standard HTML widget som ska användas vid rendering av ett formulärfält (t.ex. <input type="text">, <select>).
De minimala valideringskraven, som används i Djangos admin och i automatiskt genererade formulär.
Django levereras med dussintals inbyggda fälttyper; du kan hitta den fullständiga listan i model field reference. Du kan enkelt skriva dina egna fält om Djangos inbyggda inte räcker till; se Så här skapar du anpassade modellfält.
\nVarje fält tar en viss uppsättning fältspecifika argument (dokumenterade i model field reference). Till exempel kräver CharField (och dess underklasser) ett max_length-argument som anger storleken på databasfältet VARCHAR som används för att lagra data.
Det finns också en uppsättning gemensamma argument som är tillgängliga för alla fälttyper. Alla är valfria. De förklaras fullständigt i reference, men här är en snabb sammanfattning av de mest använda:
\nnullOm True, kommer Django att lagra tomma värden som NULL i databasen. Standard är False.
blankOm True, får fältet vara tomt. Standard är False.
Observera att detta inte är samma sak som null. null är rent databasrelaterat, medan blank är valideringsrelaterat. Om ett fält har blank=True, tillåter formulärvalideringen att ett tomt värde anges. Om ett fält har blank=False kommer fältet att vara obligatoriskt.
choicesEn sekvens av 2-värdestuplar, en mappning, en uppräkningstyp, eller en callable (som inte förväntar sig några argument och returnerar något av de tidigare formaten), att använda som val för detta fält. Om detta anges kommer standardformulärwidgeten att vara en valruta istället för standardtextfältet och begränsa valen till de angivna alternativen.
\nEn lista med valmöjligheter ser ut så här:
\nYEAR_IN_SCHOOL_CHOICES = [\n ("FR", "Freshman"),\n ("SO", "Sophomore"),\n ("JR", "Junior"),\n ("SR", "Senior"),\n ("GR", "Graduate"),\n]\nDet första elementet i varje tupel är det värde som kommer att lagras i databasen. Det andra elementet visas av fältets formulärwidget.
\nGivet en modellinstans kan visningsvärdet för ett fält med choices nås med metoden get_FOO_display(). Till exempel:
from django.db import models\n\n\nclass Person(models.Model):\n SHIRT_SIZES = {\n "S": "Small",\n "M": "Medium",\n "L": "Large",\n }\n name = models.CharField(max_length=60)\n shirt_size = models.CharField(max_length=1, choices=SHIRT_SIZES)\n>>> p = Person(name="Fred Flintstone", shirt_size="L")\n>>> p.save()\n>>> p.shirt_size\n'L'\n>>> p.get_shirt_size_display()\n'Large'\nDu kan också använda uppräkningsklasser för att definiera val på ett kortfattat sätt:
from django.db import models\n\n\nclass Runner(models.Model):\n MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")\n name = models.CharField(max_length=60)\n medal = models.CharField(blank=True, choices=MedalType, max_length=10)\nYtterligare exempel finns i modellfältets referens.
\ndefaultStandardvä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.
\ndb_defaultDet databasberäknade standardvärdet för fältet. Detta kan vara ett bokstavligt värde eller en databasfunktion.
\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.
help_textExtra ”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.
\nprimary_keyOm True, är detta fält primärnyckel för modellen.
Om du inte anger primary_key=True för några fält i din modell, kommer Django automatiskt att lägga till ett fält för att hålla primärnyckeln, så du behöver inte ange primary_key=True på något av dina fält om du inte vill åsidosätta standardbeteendet för primärnyckeln. För mer information, se Automatiska primärnyckelfält.
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. Till exempel:
\nfrom django.db import models\n\n\nclass Fruit(models.Model):\n name = models.CharField(max_length=100, primary_key=True)\n>>> fruit = Fruit.objects.create(name="Apple")\n>>> fruit.name = "Pear"\n>>> fruit.save()\n>>> Fruit.objects.values_list("name", flat=True)\n<QuerySet ['Apple', 'Pear']>\nuniqueOm True måste detta fält vara unikt i hela tabellen.
Återigen, detta är bara korta beskrivningar av de vanligaste fältalternativen. Fullständig information finns i referens för fältalternativ för vanliga modeller.
\nSom standard ger Django varje modell en automatiskt ökande primärnyckel med den typ som anges per app i AppConfig.default_auto_field eller globalt i inställningen DEFAULT_AUTO_FIELD. Till exempel:
id = models.BigAutoField(primary_key=True)\nOm du vill ange en anpassad primärnyckel, ange primary_key=True på ett av dina fält. Om Django ser att du uttryckligen har angett Field.primary_key, kommer den inte att lägga till den automatiska kolumnen id.
Varje modell kräver att exakt ett fält har primary_key=True (antingen explicit deklarerat eller automatiskt tillagt).
Varje fälttyp, med undantag för ForeignKey, ManyToManyField och OneToOneField, tar ett valfritt första positionellt argument - ett verbose-namn. Om verbose-namnet inte anges skapar Django det automatiskt med hjälp av fältets attributnamn och konverterar understrykningar till mellanslag.
I det här exemplet är det fullständiga namnet "personens förnamn":
first_name = models.CharField("person's first name", max_length=30)\nI det här exemplet är det fullständiga namnet "förnamn":
first_name = models.CharField(max_length=30)\nForeignKey, ManyToManyField och OneToOneField kräver att det första argumentet är en modellklass, så använd verbose_name nyckelordsargument:
poll = models.ForeignKey(\n Poll,\n on_delete=models.CASCADE,\n verbose_name="the related poll",\n)\nsites = models.ManyToManyField(Site, verbose_name="list of sites")\nplace = models.OneToOneField(\n Place,\n on_delete=models.CASCADE,\n verbose_name="related place",\n)\nKonventionen är att inte skriva den första bokstaven i verbose_name med stor bokstav. Django kommer automatiskt att skriva första bokstaven där det behövs.
Det är uppenbart att styrkan i relationsdatabaser ligger i att relatera tabeller till varandra. Django erbjuder sätt att definiera de tre vanligaste typerna av databasrelationer: många-till-en, många-till-många och en-till-en.
\nFör att definiera en många-till-en-relation använder du django.db.models.ForeignKey. Du använder den precis som alla andra Field-typer: genom att inkludera den som ett klassattribut i din modell.
ForeignKey kräver ett positionellt argument: den klass som modellen är relaterad till.
Om t.ex. en bilmodell har en tillverkare - dvs. en tillverkare tillverkar flera bilar men varje bil har bara en tillverkare - används följande definitioner:
\nfrom django.db import models\n\n\nclass Manufacturer(models.Model):\n # ...\n pass\n\n\nclass Car(models.Model):\n manufacturer = models.ForeignKey(Manufacturer, on_delete=models.CASCADE)\n # ...\nDu kan också skapa rekursiva relationer (ett objekt med en många-till-en-relation till sig själv) och relationer till modeller som ännu inte definierats; se modellfältreferensen för mer information.
\nDet föreslås, men krävs inte, att namnet på ett ForeignKey-fält (tillverkare i exemplet ovan) är namnet på modellen, med gemener. Du kan kalla fältet vad du vill. Till exempel:
class Car(models.Model):\n company_that_makes_it = models.ForeignKey(\n Manufacturer,\n on_delete=models.CASCADE,\n )\n # ...\nFör att definiera en relation mellan många och många använder du ManyToManyField. Du använder den precis som alla andra Field-typer: genom att inkludera den som ett klassattribut i din modell.
ManyToManyField kräver ett positionellt argument: den klass som modellen är relaterad till.
Till exempel, om en Pizza har flera Topping-objekt - det vill säga en Topping kan vara på flera pizzor och varje Pizza har flera toppings - så här skulle du representera det:
from django.db import models\n\n\nclass Topping(models.Model):\n # ...\n pass\n\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\nPrecis som med ForeignKey kan du också skapa recursiva relationer (ett objekt med en många-till-många-relation till sig själv) och relationer till modeller som ännu inte definierats.
Det föreslås, men krävs inte, att namnet på en ManyToManyField (toppings i exemplet ovan) är en plural som beskriver uppsättningen relaterade modellobjekt.
Det spelar ingen roll vilken modell som har ManyToManyField, men du bör bara lägga till den i en av modellerna - inte i båda.
Generellt sett bör ManyToManyField-instanser placeras i det objekt som ska redigeras i ett formulär. I exemplet ovan är toppings i Pizza (snarare än Topping som har en pizzas ManyToManyField ) eftersom det är mer naturligt att tänka på att en pizza har toppings än att en topping finns på flera pizzor. På det sätt som det är inställt ovan skulle formuläret Pizza låta användarna välja toppings.
ManyToManyField-fält accepterar också ett antal extra argument som förklaras i modellfältets referens. Dessa alternativ hjälper till att definiera hur relationen ska fungera; alla är valfria.
När du bara har att göra med många-till-många-relationer som att blanda och matcha pizzor och pålägg, är en standard ManyToManyField allt du behöver. Ibland kan du dock behöva associera data med relationen mellan två modeller.
Tänk till exempel på en applikation som spårar de musikgrupper som musiker tillhör. Det finns en many-to-many-relation mellan en person och de grupper som de är medlemmar i, så du kan använda en ManyToManyField för att representera denna relation. Det finns dock en hel del detaljer om medlemskapet som du kanske vill samla in, till exempel datumet då personen gick med i gruppen.
För dessa situationer tillåter Django dig att ange den modell som ska användas för att styra förhållandet många-till-många. Du kan sedan lägga till extra fält på den mellanliggande modellen. Den mellanliggande modellen är associerad med ManyToManyField med through argumentet för att peka på den modell som kommer att fungera som en mellanhand. För vårt musikexempel skulle koden se ut ungefär så här:
from django.db import models\n\n\nclass Person(models.Model):\n name = models.CharField(max_length=128)\n\n def __str__(self):\n return self.name\n\n\nclass Group(models.Model):\n name = models.CharField(max_length=128)\n members = models.ManyToManyField(Person, through="Membership")\n\n def __str__(self):\n return self.name\n\n\nclass Membership(models.Model):\n person = models.ForeignKey(Person, on_delete=models.CASCADE)\n group = models.ForeignKey(Group, on_delete=models.CASCADE)\n date_joined = models.DateField()\n invite_reason = models.CharField(max_length=64)\n\n class Meta:\n constraints = [\n models.UniqueConstraint(\n fields=["person", "group"], name="unique_person_group"\n )\n ]\nNär du konfigurerar den mellanliggande modellen anger du uttryckligen främmande nycklar till de modeller som är involverade i förhållandet många-till-många. Denna uttryckliga deklaration definierar hur de två modellerna är relaterade.
\nOm du inte vill ha flera associationer mellan samma instanser, lägg till en UniqueConstraint som inkluderar fälten from och to. Djangos automatiskt genererade many-to-many-tabeller innehåller en sådan begränsning.
Det finns några begränsningar för den mellanliggande modellen:
\nDin mellanliggande modell måste innehålla en - och endast en - främmande nyckel till källmodellen (detta skulle vara Group i vårt exempel), eller så måste du uttryckligen ange de främmande nycklar som Django ska använda för relationen med ManyToManyField.through_fields. Om du har mer än en främmande nyckel och through_fields inte anges, kommer ett valideringsfel att uppstå. En liknande begränsning gäller för den främmande nyckeln till målmodellen (detta skulle vara Person i vårt exempel).
För en modell som har ett många-till-många-förhållande till sig själv via en mellanliggande modell, är två främmande nycklar till samma modell tillåtna, men de kommer att behandlas som de två (olika) sidorna av många-till-många-förhållandet. Om through_fields inte anges, kommer den första främmande nyckeln att anses representera källsidan av ManyToManyField, medan den andra kommer att anses representera målsidan. Om det finns mer än två främmande nycklar måste du dock ange through_fields för att uttryckligen ange vilka främmande nycklar som ska användas, annars kommer ett valideringsfel att uppstå.
Nu när du har ställt in din ManyToManyField för att använda din mellanliggande modell (Membership, i det här fallet), är du redo att börja skapa några många-till-många-relationer. Du gör detta genom att skapa instanser av den mellanliggande modellen:
>>> ringo = Person.objects.create(name="Ringo Starr")\n>>> paul = Person.objects.create(name="Paul McCartney")\n>>> beatles = Group.objects.create(name="The Beatles")\n>>> m1 = Membership(\n... person=ringo,\n... group=beatles,\n... date_joined=date(1962, 8, 16),\n... invite_reason="Needed a new drummer.",\n... )\n>>> m1.save()\n>>> beatles.members.all()\n<QuerySet [<Person: Ringo Starr>]>\n>>> ringo.group_set.all()\n<QuerySet [<Group: The Beatles>]>\n>>> m2 = Membership.objects.create(\n... person=paul,\n... group=beatles,\n... date_joined=date(1960, 8, 1),\n... invite_reason="Wanted to form a band.",\n... )\n>>> beatles.members.all()\n<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>]>\nDu kan också använda add(), create() eller set() för att skapa relationer, så länge du anger through_defaults för alla obligatoriska fält:
>>> beatles.members.add(john, through_defaults={"date_joined": date(1960, 8, 1)})\n>>> beatles.members.create(\n... name="George Harrison", through_defaults={"date_joined": date(1960, 8, 1)}\n... )\n>>> beatles.members.set(\n... [john, paul, ringo, george], through_defaults={"date_joined": date(1960, 8, 1)}\n... )\nDu kanske föredrar att skapa instanser av den intermediära modellen direkt.
\nOm den anpassade genomgående tabellen som definieras av den mellanliggande modellen inte upprätthåller unikhet för paret (model1, model2), och tillåter flera värden, kommer remove()-anropet att ta bort alla mellanliggande modellinstanser:
>>> Membership.objects.create(\n... person=ringo,\n... group=beatles,\n... date_joined=date(1968, 9, 4),\n... invite_reason="You've been gone for a month and we miss you.",\n... )\n>>> beatles.members.all()\n<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>, <Person: Ringo Starr>]>\n>>> # This deletes both of the intermediate model instances for Ringo Starr\n>>> beatles.members.remove(ringo)\n>>> beatles.members.all()\n<QuerySet [<Person: Paul McCartney>]>\nMetoden clear() kan användas för att ta bort alla många-till-många-relationer för en instans:
>>> # Beatles have broken up\n>>> beatles.members.clear()\n>>> # Note that this deletes the intermediate model instances\n>>> Membership.objects.all()\n<QuerySet []>\nNär du har etablerat många-till-många-relationerna kan du ställa frågor. Precis som med vanliga many-to-many-relationer kan du ställa frågor med hjälp av attributen i den many-to-many-relaterade modellen:
\n# Find all the groups with a member whose name starts with 'Paul'\n>>> Group.objects.filter(members__name__startswith="Paul")\n<QuerySet [<Group: The Beatles>]>\nEftersom du använder en intermediär modell kan du också ställa frågor om dess attribut:
\n# Find all the members of the Beatles that joined after 1 Jan 1961\n>>> Person.objects.filter(\n... group__name="The Beatles", membership__date_joined__gt=date(1961, 1, 1)\n... )\n<QuerySet [<Person: Ringo Starr]>\nOm du behöver få tillgång till information om ett medlemskap kan du göra det genom att direkt fråga efter modellen Membership:
>>> ringos_membership = Membership.objects.get(group=beatles, person=ringo)\n>>> ringos_membership.date_joined\ndatetime.date(1962, 8, 16)\n>>> ringos_membership.invite_reason\n'Needed a new drummer.'\nEtt annat sätt att komma åt samma information är genom att fråga many-to-many reverse relationship från ett Person-objekt:
>>> ringos_membership = ringo.membership_set.get(group=beatles)\n>>> ringos_membership.date_joined\ndatetime.date(1962, 8, 16)\n>>> ringos_membership.invite_reason\n'Needed a new drummer.'\nFör att definiera en en-till-en-relation använder du OneToOneField. Du använder den precis som alla andra Field-typer: genom att inkludera den som ett klassattribut i din modell.
Detta är mest användbart på primärnyckeln för ett objekt när det objektet ”utvidgar” ett annat objekt på något sätt.
\nOneToOneField kräver ett positionsargument: den klass som modellen är relaterad till.
Till exempel, om du byggde en databas med ”platser”, skulle du bygga ganska standard saker som adress, telefonnummer, etc. i databasen. Sedan, om du vill bygga en databas med restauranger ovanpå platserna, istället för att upprepa dig själv och replikera dessa fält i Restaurant-modellen, kan du göra Restaurant har en OneToOneField till Place (eftersom en restaurang ”är en” plats; i själva verket, för att hantera detta skulle du vanligtvis använda arv, vilket innebär en implicit en-till-en-relation).
Precis som med ForeignKey kan en rekursiv relation definieras och referenser till ännu odefinierade modeller kan göras.
OneToOneField-fält accepterar också ett valfritt parent_link-argument.
OneToOneField klasser brukade automatiskt bli den primära nyckeln i en modell. Detta är inte längre sant (även om du manuellt kan skicka in argumentet primary_key om du vill). Således är det nu möjligt att ha flera fält av typen OneToOneField på en enda modell.
Det är helt OK att relatera en modell till en modell från en annan app. För att göra detta importerar du den relaterade modellen högst upp i filen där din modell definieras. Hänvisa sedan till den andra modellklassen där det behövs. Till exempel:
\nfrom django.db import models\nfrom geography.models import ZipCode\n\n\nclass Restaurant(models.Model):\n # ...\n zip_code = models.ForeignKey(\n ZipCode,\n on_delete=models.SET_NULL,\n blank=True,\n null=True,\n )\nAlternativt kan du använda en latent referens till den relaterade modellen, som anges som en sträng i formatet "app_label.ModelName". Detta kräver inte att den relaterade modellen importeras. Till exempel:
from django.db import models\n\n\nclass Restaurant(models.Model):\n # ...\n zip_code = models.ForeignKey(\n "geography.ZipCode",\n on_delete=models.SET_NULL,\n blank=True,\n null=True,\n )\nSe lazy relationships för mer information.
\nDjango lägger vissa restriktioner på modellfältnamn:
\nEtt fältnamn kan inte vara ett reserverat ord i Python, eftersom det skulle resultera i ett syntaxfel i Python. Ett exempel:
\nclass Example(models.Model):\n pass = models.IntegerField() # 'pass' is a reserved word!\nEtt fältnamn kan inte innehålla mer än ett understreck i en rad, på grund av hur Djangos syntax för frågeuppslagning fungerar. Till exempel:
\nclass Example(models.Model):\n foo__bar = models.IntegerField() # 'foo__bar' has two underscores!\nEtt fältnamn kan av samma skäl inte sluta med ett understreck.
Ett fältnamn kan inte vara check, eftersom detta skulle åsidosätta check-ramverkets Model.check()-metod.
Dessa begränsningar kan dock kringgås, eftersom fältnamnet inte nödvändigtvis måste överensstämma med databasens kolumnnamn. Se alternativet db_column.
Reserverade SQL-ord, såsom ”join”, ”where” eller ”select”, är tillåtna som modellfältnamn, eftersom Django escapar alla databastabellnamn och kolumnnamn i varje underliggande SQL-fråga. Den använder citatsyntaxen för din specifika databasmotor.
\nOm något av de befintliga modellfälten inte kan användas för dina ändamål, eller om du vill dra nytta av några mindre vanliga kolumntyper i databasen, kan du skapa en egen fältklass. Fullständig information om hur du skapar egna fält finns i Så här skapar du anpassade modellfält.
\nMetaLink to this heading#Ge din modell metadata genom att använda en inre class Meta, så här:
from django.db import models\n\n\nclass Ox(models.Model):\n horn_length = models.IntegerField()\n\n class Meta:\n ordering = ["horn_length"]\n verbose_name_plural = "oxen"\nModellmetadata är ”allt som inte är ett fält”, t.ex. ordningsalternativ (ordering), databasens tabellnamn (db_table) eller mänskligt läsbara namn i singular och plural (verbose_name och verbose_name_plural). Inga av dessa är obligatoriska och det är helt frivilligt att lägga till class Meta till en modell.
En fullständig lista över alla möjliga Meta-alternativ finns i modellalternativreferens.
objektDet viktigaste attributet för en modell är Manager. Det är det gränssnitt genom vilket databasfrågor tillhandahålls till Django-modeller och används för att hämta instanser från databasen. Om ingen anpassad Manager är definierad är standardnamnet objects. Managers är endast tillgängliga via modellklasser, inte modellinstanserna.
Definiera anpassade metoder på en modell för att lägga till anpassad funktionalitet på ”radnivå” till dina objekt. Medan Manager-metoder är avsedda att göra ”tabellomfattande” saker, bör modellmetoder agera på en viss modellinstans.
Detta är en värdefull teknik för att hålla affärslogiken på ett ställe - modellen.
\nTill exempel har denna modell några anpassade metoder:
\nfrom django.db import models\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n birth_date = models.DateField()\n\n def baby_boomer_status(self):\n "Returns the person's baby-boomer status."\n import datetime\n\n if self.birth_date < datetime.date(1945, 8, 1):\n return "Pre-boomer"\n elif self.birth_date < datetime.date(1965, 1, 1):\n return "Baby boomer"\n else:\n return "Post-boomer"\n\n @property\n def full_name(self):\n "Returns the person's full name."\n return f"{self.first_name} {self.last_name}"\nDen sista metoden i detta exempel är en property.
\nI model instance reference finns en komplett lista över methods som automatiskt ges till varje modell. Du kan åsidosätta de flesta av dessa - se Åsidosätta fördefinierade modellmetoder nedan - men det finns ett par som du nästan alltid vill definiera:
\n__str__()En ”magisk metod” i Python som returnerar en strängrepresentation av valfritt objekt. Det här är vad Python och Django kommer att använda när en modellinstans måste tvingas och visas som en vanlig sträng. Framför allt händer detta när du visar ett objekt i en interaktiv konsol eller i administratören.
\nDu vill alltid definiera den här metoden; standardinställningen är inte alls till någon större hjälp.
\nget_absolute_url()Detta talar om för Django hur man beräknar URL:en för ett objekt. Django använder detta i sitt admin-gränssnitt och när som helst när de behöver räkna ut en URL för ett objekt.
\nAlla objekt som har en URL som identifierar dem på ett unikt sätt bör definiera denna metod.
\nDet finns en annan uppsättning modellmetoder som kapslar in en massa databasbeteenden som du vill anpassa. I synnerhet kommer du ofta att vilja ändra hur save() och delete() fungerar.
Det står dig fritt att åsidosätta dessa metoder (och alla andra modellmetoder) för att ändra beteendet.
\nEtt klassiskt användningsfall för att åsidosätta de inbyggda metoderna är om du vill att något ska hända när du sparar ett objekt. Till exempel (se save() för dokumentation av de parametrar den accepterar):
from django.db import models\n\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n tagline = models.TextField()\n\n def save(self, **kwargs):\n do_something()\n super().save(**kwargs) # Call the "real" save() method.\n do_something_else()\nDu kan också förhindra sparande:
\nfrom django.db import models\n\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n tagline = models.TextField()\n\n def save(self, **kwargs):\n if self.name == "Yoko Ono's blog":\n return # Yoko shall never have her own blog!\n else:\n super().save(**kwargs) # Call the "real" save() method.\nDet är viktigt att komma ihåg att anropa superklassmetoden - det är det där med super().save(**kwargs) - för att säkerställa att objektet fortfarande sparas i databasen. Om du glömmer att anropa superklassmetoden kommer standardbeteendet inte att ske och databasen kommer inte att beröras.
Det är också viktigt att du skickar igenom de argument som kan skickas till modellmetoden - det är vad **kwargs-biten gör. Django kommer från tid till annan att utöka kapaciteten hos inbyggda modellmetoder och lägga till nya nyckelordsargument. Om du använder **kwargs i dina metoddefinitioner, är du garanterad att din kod automatiskt kommer att stödja dessa argument när de läggs till.
Om du vill uppdatera ett fältvärde i metoden save(), kanske du också vill lägga till fältet i nyckelordsargumentet update_fields. Detta kommer att säkerställa att fältet sparas när update_fields anges. Till exempel:
from django.db import models\nfrom django.utils.text import slugify\n\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n slug = models.TextField()\n\n def save(self, **kwargs):\n self.slug = slugify(self.name)\n if (\n update_fields := kwargs.get("update_fields")\n ) is not None and "name" in update_fields:\n kwargs["update_fields"] = {"slug"}.union(update_fields)\n super().save(**kwargs)\nSe Ange vilka fält som ska sparas för mer information.
\n\nEtt annat vanligt mönster är att skriva anpassade SQL-satser i modellmetoder och metoder på modulnivå. Mer information om hur du använder raw SQL finns i dokumentationen på using raw SQL.
\nModellarv i Django fungerar nästan identiskt med hur normalt klassarv fungerar i Python, men grunderna i början av sidan bör fortfarande följas. Det betyder att basklassen bör underordna sig django.db.models.Model.
Det enda beslut du behöver fatta är om du vill att föräldramodellerna ska vara modeller i sig (med egna databastabeller), eller om föräldrarna bara är innehavare av gemensam information som bara kommer att vara synlig genom barnmodellerna.
\nDet finns tre olika typer av arv som är möjliga i Django.
\nOfta vill du bara använda den överordnade klassen för att hålla information som du inte vill behöva skriva ut för varje underordnad modell. Den här klassen kommer aldrig att användas isolerat, så abstrakta basklasser är vad du är ute efter.
Om du subklassar en befintlig modell (kanske något från en helt annan applikation) och vill att varje modell ska ha sin egen databastabell är Arv från flera tabeller rätt väg att gå.
Slutligen, om du bara vill ändra en modells beteende på Python-nivå utan att ändra modellens fält på något sätt, kan du använda Proxy-modeller.
Abstrakta basklasser är användbara när du vill lägga in viss gemensam information i ett antal andra modeller. Du skriver din basklass och sätter abstract=True i Meta klassen. Denna modell kommer då inte att användas för att skapa någon databastabell. Istället, när den används som basklass för andra modeller, kommer dess fält att läggas till fälten i underklassen.
Ett exempel:
\nfrom django.db import models\n\n\nclass CommonInfo(models.Model):\n name = models.CharField(max_length=100)\n age = models.PositiveIntegerField()\n\n class Meta:\n abstract = True\n\n\nclass Student(CommonInfo):\n home_group = models.CharField(max_length=5)\nModellen Student kommer att ha tre fält: name, age och home_group. Modellen CommonInfo kan inte användas som en vanlig Django-modell, eftersom det är en abstrakt basklass. Den genererar inte en databastabell eller har en manager och kan inte instansieras eller sparas direkt.
Fält som ärvs från abstrakta basklasser kan åsidosättas med ett annat fält eller värde, eller tas bort med None.
För många användningsområden är den här typen av modellarv exakt vad du vill ha. Det ger ett sätt att faktorisera ut gemensam information på Python-nivå, samtidigt som det bara skapas en databastabell per underordnad modell på databasnivå.
\nMeta arvLink to this heading#När en abstrakt basklass skapas gör Django alla Meta innerklasser som du deklarerat i basklassen tillgängliga som attribut. Om en underordnad klass inte deklarerar sin egen Meta-klass, kommer den att ärva förälderns Meta. Om barnet vill utöka förälderns Meta-klass kan det subklassa den. Till exempel:
\nfrom django.db import models\n\n\nclass CommonInfo(models.Model):\n # ...\n class Meta:\n abstract = True\n ordering = ["name"]\n\n\nclass Student(CommonInfo):\n # ...\n class Meta(CommonInfo.Meta):\n db_table = "student_info"\nDjango gör en justering av klassen Meta för en abstrakt basklass: innan attributet Meta installeras, sätts abstract=False. Detta innebär att barn till abstrakta basklasser inte automatiskt blir abstrakta klasser själva. För att skapa en abstrakt basklass som ärver från en annan abstrakt basklass måste du uttryckligen ställa in abstract=True på barnet.
Vissa attribut är inte meningsfulla att inkludera i Meta-klassen för en abstrakt basklass. Att inkludera db_table skulle till exempel innebära att alla underordnade klasser (de som inte anger sin egen Meta) skulle använda samma databastabell, vilket nästan säkert inte är vad du vill.
På grund av hur Python-arvet fungerar, om en underordnad klass ärver från flera abstrakta basklasser, kommer endast Meta-alternativen från den första listade klassen att ärvas som standard. För att ärva Meta-alternativ från flera abstrakta basklasser måste du uttryckligen deklarera Meta-arvet. Till exempel:
\nfrom django.db import models\n\n\nclass CommonInfo(models.Model):\n name = models.CharField(max_length=100)\n age = models.PositiveIntegerField()\n\n class Meta:\n abstract = True\n ordering = ["name"]\n\n\nclass Unmanaged(models.Model):\n class Meta:\n abstract = True\n managed = False\n\n\nclass Student(CommonInfo, Unmanaged):\n home_group = models.CharField(max_length=5)\n\n class Meta(CommonInfo.Meta, Unmanaged.Meta):\n pass\nDen andra typen av modellarv som stöds av Django är när varje modell i hierarkin är en modell i sig själv. Varje modell motsvarar sin egen databastabell och kan efterfrågas och skapas individuellt. Arvsrelationen introducerar länkar mellan barnmodellen och var och en av dess föräldrar (via en automatiskt skapad OneToOneField). Till exempel:
from django.db import models\n\n\nclass Place(models.Model):\n name = models.CharField(max_length=50)\n address = models.CharField(max_length=80)\n\n\nclass Restaurant(Place):\n serves_hot_dogs = models.BooleanField(default=False)\n serves_pizza = models.BooleanField(default=False)\nAlla fält i Place kommer också att finnas tillgängliga i Restaurant, även om uppgifterna kommer att finnas i en annan databastabell. Så dessa är båda möjliga:
>>> Place.objects.filter(name="Bob's Cafe")\n>>> Restaurant.objects.filter(name="Bob's Cafe")\nOm du har ett Place som också är en Restaurant, kan du komma från Place-objektet till Restaurant-objektet genom att använda den gemena versionen av modellnamnet:
>>> p = Place.objects.get(id=12)\n# If p is a Restaurant object, this will give the child class:\n>>> p.restaurant\n<Restaurant: ...>\nMen om p i exemplet ovan inte var en Restaurant (den hade skapats direkt som ett Place-objekt eller var förälder till någon annan klass), skulle en hänvisning till p.restaurant ge upphov till ett Restaurant.DoesNotExist undantag.
Den automatiskt skapade OneToOneField på Restaurant som länkar den till Place ser ut så här:
place_ptr = models.OneToOneField(\n Place,\n on_delete=models.CASCADE,\n parent_link=True,\n primary_key=True,\n)\nDu kan åsidosätta det fältet genom att deklarera din egen OneToOneField med parent_link=True på Restaurant.
Meta och arv av flera tabellerLink to this heading#I arvssituationen med flera tabeller är det inte meningsfullt för en underordnad klass att ärva från sin förälders Meta-klass. Alla Meta-alternativ har redan tillämpats på föräldraklassen och att tillämpa dem igen skulle normalt bara leda till motsägelsefullt beteende (detta står i kontrast till fallet med den abstrakta basklassen, där basklassen inte existerar i sin egen rätt).
\nSå en barnmodell har inte tillgång till sin förälders Meta-klass. Det finns dock några få begränsade fall där barnet ärver beteende från föräldern: om barnet inte anger ett ordering-attribut eller ett get_latest_by-attribut, kommer det att ärva dessa från sin förälder.
Om föräldern har en ordning och du inte vill att barnet ska ha någon naturlig ordning kan du uttryckligen inaktivera den:
\nclass ChildModel(ParentModel):\n # ...\n class Meta:\n # Remove parent's ordering effect\n ordering = []\nBecause multi-table inheritance uses an implicit\nOneToOneField to link the child and\nthe parent, it’s possible to move from the parent down to the child,\nas in the above example. However, this uses up the name that is the\ndefault related_name value for\nForeignKey and\nManyToManyField relations. If you\nare putting those types of relations on a subclass of the parent model, you\nmust specify the related_name\nattribute on each such field. If you forget, Django will raise a validation\nerror.
Om vi till exempel använder ovanstående klass Place igen, låt oss skapa en annan underklass med en ManyToManyField:
class Supplier(Place):\n customers = models.ManyToManyField(Place)\nDetta resulterar i felet:
\nReverse query name for 'Supplier.customers' clashes with reverse query\nname for 'Supplier.place_ptr'.\n\nHINT: Add or change a related_name argument to the definition for\n'Supplier.customers' or 'Supplier.place_ptr'.\nOm du lägger till related_name i fältet customers på följande sätt skulle felet lösas: models.ManyToManyField(Place, related_name='provider').
Som nämnts kommer Django automatiskt att skapa en OneToOneField som länkar din underordnade klass tillbaka till alla icke-abstrakta överordnade modeller. Om du vill styra namnet på attributet som länkar tillbaka till föräldern kan du skapa din egen OneToOneField och ställa in parent_link=True för att ange att ditt fält är länken tillbaka till föräldraklassen.
När du använder multi-table inheritance skapas en ny databastabell för varje underklass av en modell. Detta är vanligtvis det önskade beteendet, eftersom underklassen behöver en plats för att lagra eventuella ytterligare datafält som inte finns i basklassen. Ibland vill man dock bara ändra Python-beteendet för en modell - kanske för att ändra standardhanteraren eller lägga till en ny metod.
\nDetta är vad arv av proxymodeller är till för: att skapa en proxy för den ursprungliga modellen. Du kan skapa, ta bort och uppdatera instanser av proxymodellen och alla data sparas som om du använde den ursprungliga (icke-proxyiserade) modellen. Skillnaden är att du kan ändra saker som standardmodellens beställning eller standardhanteraren i proxyn utan att behöva ändra originalet.
\nProxy-modeller deklareras som vanliga modeller. Du talar om för Django att det är en proxymodell genom att ställa in attributet proxy i klassen Meta till True.
Anta till exempel att du vill lägga till en metod i modellen Person. Du kan göra det så här:
from django.db import models\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=30)\n last_name = models.CharField(max_length=30)\n\n\nclass MyPerson(Person):\n class Meta:\n proxy = True\n\n def do_something(self):\n # ...\n pass\nKlassen MyPerson arbetar i samma databastabell som sin överordnade klass Person. I synnerhet kommer alla nya instanser av Person också att vara tillgängliga via MyPerson, och vice versa:
>>> p = Person.objects.create(first_name="foobar")\n>>> MyPerson.objects.get(first_name="foobar")\n<MyPerson: foobar>\nDu kan också använda en proxymodell för att definiera en annan standardbeställning på en modell. Du kanske inte alltid vill beställa modellen Person, men regelbundet beställa efter attributet last_name när du använder proxy:
class OrderedPerson(Person):\n class Meta:\n ordering = ["last_name"]\n proxy = True\nNu kommer vanliga Person-frågor att vara oordnade och OrderedPerson-frågor kommer att vara ordnade efter efternamn.
Proxy-modeller ärver Meta-attribut :ref:` på samma sätt som vanliga modeller <meta-and-multi-table-inheritance>`.
QuerySet returnerar fortfarande den modell som begärdesLink to this heading#Det finns inget sätt att få Django att returnera till exempel ett MyPerson-objekt när du frågar efter Person-objekt. En queryset för Person-objekt kommer att returnera dessa typer av objekt. Hela poängen med proxyobjekt är att kod som förlitar sig på den ursprungliga Person kommer att använda dem och din egen kod kan använda de tillägg du inkluderade (som ingen annan kod förlitar sig på ändå). Det är inte ett sätt att ersätta Person (eller någon annan) modell överallt med något av din egen skapelse.
En proxymodell måste ärva från exakt en icke-abstrakt modellklass. Du kan inte ärva från flera icke-abstrakta modeller eftersom proxymodellen inte ger någon koppling mellan raderna i de olika databastabellerna. En proxymodell kan ärva från hur många abstrakta modellklasser som helst, förutsatt att de inte definierar några modellfält. En proxymodell kan också ärva från ett valfritt antal proxymodeller som delar en gemensam icke-abstrakt föräldraklass.
\nOm du inte anger några modellhanterare för en proxymodell ärver den hanterarna från sina modellföräldrar. Om du definierar en hanterare för proxymodellen blir den standard, även om alla hanterare som definierats för de överordnade klasserna fortfarande är tillgängliga.
\nOm vi fortsätter med vårt exempel från ovan kan du ändra standardhanteraren som används när du frågar Person-modellen så här:
from django.db import models\n\n\nclass NewManager(models.Manager):\n # ...\n pass\n\n\nclass MyPerson(Person):\n objects = NewManager()\n\n class Meta:\n proxy = True\nOm du vill lägga till en ny hanterare i proxyn utan att ersätta den befintliga standardhanteraren kan du använda de tekniker som beskrivs i dokumentationen custom manager: skapa en basklass som innehåller de nya hanterarna och ärva den efter den primära basklassen:
\n# Create an abstract class for the new manager.\nclass ExtraManagers(models.Model):\n secondary = NewManager()\n\n class Meta:\n abstract = True\n\n\nclass MyPerson(Person, ExtraManagers):\n class Meta:\n proxy = True\nDu kommer förmodligen inte att behöva göra det här särskilt ofta, men när du gör det är det möjligt.
\nArv av proxymodeller kan se ut ungefär som att skapa en ohanterad modell med hjälp av attributet managed på en modells Meta-klass.
Med en noggrann inställning av Meta.db_table kan du skapa en ohanterad modell som skuggar en befintlig modell och lägger till Python-metoder till den. Det skulle dock vara mycket repetitivt och bräckligt eftersom du måste hålla båda kopiorna synkroniserade om du gör några ändringar.
Å andra sidan är proxymodeller avsedda att bete sig exakt som den modell som de är proxy för. De är alltid synkroniserade med den överordnade modellen eftersom de direkt ärver dess fält och hanterare.
\nDe allmänna reglerna är:
\nOm du speglar en befintlig modell eller databastabell och inte vill ha alla kolumner i den ursprungliga databastabellen, använd Meta.managed=False. Det alternativet är normalt användbart för modellering av databasvyer och tabeller som inte är under kontroll av Django.
Om du vill ändra Python-beteendet för en modell, men behålla alla fält som finns i originalet, använder du Meta.proxy=True. Detta ställer in saker så att proxymodellen är en exakt kopia av lagringsstrukturen för den ursprungliga modellen när data sparas.
Precis som med Pythons subklassning är det möjligt för en Django-modell att ärva från flera överordnade modeller. Tänk på att Pythons normala regler för namnupplösning gäller. Den första basklassen som ett visst namn (t.ex. Meta) förekommer i kommer att vara den som används; till exempel innebär detta att om flera föräldrar innehåller en Meta-klass, kommer endast den första att användas och alla andra kommer att ignoreras.
\nI allmänhet behöver du inte ärva från flera föräldrar. Det främsta användningsfallet där detta är användbart är för ”mix-in”-klasser: att lägga till ett visst extra fält eller en viss metod till varje klass som ärver mix-in. Försök att hålla dina arvshierarkier så enkla och okomplicerade som möjligt så att du inte behöver kämpa för att ta reda på varifrån en viss information kommer.
\nObservera att om du ärver från flera modeller som har ett gemensamt primärnyckelfält id kommer ett fel att uppstå. För att korrekt använda multipelt arv kan du använda en explicit AutoField i basmodellerna:
class Article(models.Model):\n article_id = models.AutoField(primary_key=True)\n ...\n\n\nclass Book(models.Model):\n book_id = models.AutoField(primary_key=True)\n ...\n\n\nclass BookReview(Book, Article):\n pass\nEller använd en gemensam förfader för att hålla AutoField. Detta kräver att man använder en explicit OneToOneField från varje överordnad modell till den gemensamma förfadern för att undvika en krock mellan de fält som genereras automatiskt och ärvs av underordnade modeller:
class Piece(models.Model):\n pass\n\n\nclass Article(Piece):\n article_piece = models.OneToOneField(\n Piece, on_delete=models.CASCADE, parent_link=True\n )\n ...\n\n\nclass Book(Piece):\n book_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)\n ...\n\n\nclass BookReview(Book, Article):\n pass\nI normalt Python-klassarv är det tillåtet för en underordnad klass att åsidosätta alla attribut från den överordnade klassen. I Django är detta vanligtvis inte tillåtet för modellfält. Om en icke-abstrakt modellbasklass har ett fält som heter author, kan du inte skapa ett annat modellfält eller definiera ett attribut som heter author i någon klass som ärver från den basklassen.
Denna begränsning gäller inte för modellfält som ärvs från en abstrakt modell. Sådana fält kan åsidosättas med ett annat fält eller värde, eller tas bort genom att ange field_name = None.
Åsidosättande av fält i en överordnad modell leder till svårigheter inom områden som initialisering av nya instanser (specificera vilket fält som initialiseras i Model.__init__) och serialisering. Det här är funktioner som normalt Python-klassarv inte behöver hantera på samma sätt, så skillnaden mellan Django-modellarv och Python-klassarv är inte godtycklig.
Denna begränsning gäller endast för attribut som är Field-instanser. Normala Python-attribut kan åsidosättas om du vill. Det gäller också bara namnet på attributet som Python ser det: om du manuellt anger databasens kolumnnamn kan du ha samma kolumnnamn som visas i både ett barn och en förfadersmodell för arv i flera tabeller (de är kolumner i två olika databastabeller).
Django kommer att ge upphov till ett FieldError om du åsidosätter något modellfält i någon förfadersmodell.
Observera att på grund av det sätt som fält löses under klassdefinitionen, löses modellfält som ärvs från flera abstrakta föräldramodeller i en strikt djupförsta ordning. Detta står i kontrast till standard Python MRO, som löses i bredd-först ordning i fall av diamantformat arv. Denna skillnad påverkar endast komplexa modellhierarkier, som du (enligt rådet ovan) bör försöka undvika.
\nMed kommandot manage.py startapp skapas en programstruktur som innehåller filen models.py. Om du har många modeller kan det vara bra att organisera dem i separata filer.
För att göra det skapar du ett models-paket. Ta bort models.py och skapa en katalog myapp/models/ med en fil __init__.py och filerna för att lagra dina modeller. Du måste importera modellerna i filen __init__.py.
Om du t.ex. har organic.py och synthetic.py i katalogen models:
myapp/modeller/__init__.pyfrom .organic import Person\nfrom .synthetic import Robot\nAtt explicit importera varje modell i stället för att använda from .models import * har fördelarna att namnrymden inte blir rörig, att koden blir mer läsbar och att kodanalysverktygen förblir användbara.