Alternativ för modell MetaLink to this heading#

abstraktLink to this heading#

Options.abstractLink to this definition#

Om abstract = True, kommer denna modell att vara en abstrakt basklass.

app_labelLink to this heading#

Options.app_labelLink to this definition#

Om en modell definieras utanför en applikation i INSTALLED_APPS, måste den ange vilken app den tillhör:

Code

app_label = "myapp"

Om du vill representera en modell med formatet app_label.object_name eller app_label.model_name kan du använda model._meta.label respektive model._meta.label_lower.

bas_chefsnamnLink to this heading#

Options.base_manager_nameLink to this definition#

Attributnamnet på hanteraren, t.ex. 'objects', som ska användas för modellens _base_manager.

db_tableLink to this heading#

Options.db_tableLink to this definition#

Namnet på den databastabell som ska användas för modellen:

Code

db_table = "music_album"

db_table_commentLink to this heading#

Options.db_table_commentLink to this definition#

Kommentaren om databastabellen som ska användas för den här modellen. Det är användbart för att dokumentera databastabeller för personer med direkt databasåtkomst som kanske inte tittar på din Django-kod. Till exempel:

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

db_tablespaceLink to this heading#

Options.db_tablespaceLink to this definition#

Namnet på det databas-tabellutrymme som ska användas för den här modellen. Standardvärdet är projektets DEFAULT_TABLESPACE-inställning, om den är inställd. Om backend inte stöder tablespaces ignoreras detta alternativ.

förvaltarens_namnLink to this heading#

Options.default_manager_nameLink to this definition#

Namnet på den manager som ska användas för modellens _default_manager.

förvaltat_relaterat_namnLink to this heading#

Options.default_related_nameLink to this definition#

Det namn som kommer att användas som standard för relationen från ett relaterat objekt tillbaka till detta. Standardvärdet är <model_name>_set.

Detta alternativ anger också related_query_name.

Eftersom det omvända namnet för ett fält bör vara unikt, bör du vara försiktig om du tänker underklassa din modell. För att undvika namnkollisioner bör en del av namnet innehålla '%(app_label)s' och '%(model_name)s', som ersätts av namnet på den applikation som modellen finns i respektive namnet på modellen, båda med gemener. Se stycket om -relaterade namn för abstrakta modeller.

”Hämta senaste byLink to this heading#

Options.get_latest_byLink to this definition#

Namnet på ett fält eller en lista med fältnamn i modellen, vanligtvis DateField, DateTimeField eller IntegerField. Detta anger det eller de standardfält som ska användas i din modell Manager:s metoder latest() och earliest().

Exempel:

Code

# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]

Se latest()-dokumenten för mer information.

hanteradLink to this heading#

Options.managedLink to this definition#

Standardvärdet är True, vilket innebär att Django kommer att skapa lämpliga databastabeller i migrate eller som en del av migreringar och ta bort dem som en del av ett flush-hanteringskommando. Det vill säga, Django hanterar databastabellernas livscykler.

Om False, kommer inga åtgärder för att skapa, ändra eller ta bort databastabeller att utföras för denna modell. Detta är användbart om modellen representerar en befintlig tabell eller en databasvy som har skapats på något annat sätt. Detta är den enda skillnaden när managed=False. Alla andra aspekter av modellhanteringen är exakt desamma som normalt. Detta inkluderar

1. Lägga till ett automatiskt primärnyckelfält i modellen om du inte deklarerar det. För att undvika förvirring för senare kodläsare rekommenderas att du anger alla kolumner från den databastabell du modellerar när du använder ohanterade modeller.

2. Om en modell med managed=False innehåller en ManyToManyField som pekar på en annan ohanterad modell, så kommer inte heller den mellanliggande tabellen för many-to-many join att skapas. Men den mellanliggande tabellen mellan en hanterad och en ohanterad modell kommer att skapas.

   Om du behöver ändra detta standardbeteende skapar du den mellanliggande tabellen som en explicit modell (med managed inställt efter behov) och använder attributet ManyToManyField.through för att relationen ska använda din anpassade modell.

För tester som involverar modeller med managed=False är det upp till dig att se till att rätt tabeller skapas som en del av testinställningen.

Om du är intresserad av att ändra beteendet på Python-nivå för en modellklass, skulle du kunna använda managed=False och skapa en kopia av en befintlig modell. Det finns dock ett bättre tillvägagångssätt för den situationen: Proxy-modeller.

”ordning_med_respekt_förLink to this heading#

Options.order_with_respect_toLink to this definition#

Gör detta objekt beställningsbart med avseende på det angivna fältet, vanligtvis en ForeignKey. Detta kan användas för att göra relaterade objekt beställningsbara med avseende på ett överordnat objekt. Till exempel:, om ett Answer relaterar till ett Question-objekt, och en fråga har mer än ett svar, och ordningen på svaren spelar roll, skulle du göra så här:

Code

from django.db import models


class Question(models.Model):
    text = models.TextField()
    # ...


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = "question"

När order_with_respect_to är inställd, tillhandahålls två ytterligare metoder för att hämta och ställa in ordningen på de relaterade objekten: get_RELATED_order() och set_RELATED_order(), där RELATED är modellnamnet med gemener. Om man t.ex. antar att ett Question-objekt har flera relaterade Answer-objekt, innehåller den returnerade listan primärnycklarna för de relaterade Answer-objekten:

Python console

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

Ordningen på ett Question-objekts relaterade Answer-objekt kan ställas in genom att skicka in en lista med Answer-primärnycklar:

Python console

>>> question.set_answer_order([3, 1, 2])

De relaterade objekten får också två metoder, get_next_in_order() och get_previous_in_order(), som kan användas för att komma åt dessa objekt i rätt ordning. Anta att objekten Answer är ordnade efter id:

Python console

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

beställningLink to this heading#

Options.orderingLink to this definition#

Standardordningen för objektet, för användning vid hämtning av listor över objekt:

Code

ordering = ["-order_date"]

Detta är en tupel eller lista med strängar och/eller frågeuttryck. Varje sträng är ett fältnamn med ett valfritt prefix ”-”, som anger fallande ordning. Fält utan ett inledande ”-” ordnas i stigande ordning. Använd strängen ”?” för slumpmässig ordning.

Om du t.ex. vill sortera fältet pub_date i stigande ordning använder du följande:

Code

ordering = ["pub_date"]

För att beställa efter pub_date i fallande ordning, använd detta:

Code

ordering = ["-pub_date"]

För att beställa efter pub_date i fallande ordning, sedan efter author i stigande ordning, använd detta:

Code

ordering = ["-pub_date", "author"]

Du kan också använda frågeuttryck. För att sortera efter author stigande och få null-värden att sorteras sist, använd detta:

Code

from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]

behörigheterLink to this heading#

Options.permissionsLink to this definition#

Extra behörigheter som ska anges i behörighetstabellen när du skapar det här objektet. Behörigheter för att lägga till, ändra, ta bort och visa skapas automatiskt för varje modell. I det här exemplet anges en extra behörighet, can_deliver_pizzas:

Code

permissions = [("can_deliver_pizzas", "Can deliver pizzas")]

Detta är en lista eller tupel av 2-tuplar i formatet (permission_code, human_readable_permission_name).

standard_behörigheterLink to this heading#

Options.default_permissionsLink to this definition#

Standardvärdet är ('add', 'change', 'delete', 'view'). Du kan anpassa den här listan, till exempel genom att ange en tom lista om din app inte kräver någon av standardbehörigheterna. Den måste anges för modellen innan modellen skapas av migrate för att förhindra att utelämnade behörigheter skapas.

proxyLink to this heading#

Options.proxyLink to this definition#

Om proxy = True, kommer en modell som subklassar en annan modell att behandlas som en proxymodell.

krävda_db_funktionerLink to this heading#

Options.required_db_featuresLink to this definition#

Lista över databasfunktioner som den aktuella anslutningen bör ha så att modellen beaktas under migreringsfasen. Om du t.ex. anger ['gis_enabled'] i den här listan kommer modellen endast att synkroniseras med GIS-aktiverade databaser. Det är också bra att hoppa över vissa modeller när du testar med flera databasbackends. Undvik relationer mellan modeller som kanske eller kanske inte skapas eftersom ORM inte hanterar detta.

krävd_db_leverantörLink to this heading#

Options.required_db_vendorLink to this definition#

Namn på en databasleverantör som stöds och som denna modell är specifik för. Aktuella inbyggda leverantörsnamn är: sqlite, postgresql, mysql, oracle. Om detta attribut inte är tomt och den aktuella anslutningsleverantören inte matchar det, kommer modellen inte att synkroniseras.

Välj_vid_sparandeLink to this heading#

Options.select_on_saveLink to this definition#

Bestämmer om Django ska använda pre-1.6 django.db.models.Model.save()-algoritmen. Den gamla algoritmen använder SELECT för att avgöra om det finns en befintlig rad som ska uppdateras. Den nya algoritmen försöker med en UPDATE direkt. I vissa sällsynta fall är UPDATE av en befintlig rad inte synlig för Django. Ett exempel är PostgreSQL ON UPDATE trigger som returnerar NULL. I sådana fall kommer den nya algoritmen att sluta göra en INSERT även när en rad finns i databasen.

Vanligtvis finns det inget behov av att ställa in detta attribut. Standardvärdet är False.

Se django.db.models.Model.save() för mer information om den gamla och nya sparalgoritmen.

indexLink to this heading#

Options.indexesLink to this definition#

En lista över index som du vill definiera på modellen:

Code

from django.db import models


class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=["last_name", "first_name"]),
            models.Index(fields=["first_name"], name="first_name_idx"),
        ]

unique_togetherLink to this heading#

Options.unique_togetherLink to this definition#

Uppsättningar av fältnamn som tillsammans måste vara unika:

Code

unique_together = [["driver", "restaurant"]]

Detta är en lista över listor som måste vara unika när de betraktas tillsammans. Den används i Django-administratören och verkställs på databasnivå (dvs. lämpliga UNIQUE-satser ingår i CREATE TABLE-satsen).

För enkelhetens skull kan unique_together vara en enda lista när det handlar om en enda uppsättning fält:

Code

unique_together = ["driver", "restaurant"]

En ManyToManyField kan inte inkluderas i unique_together. (Det är inte klart vad det ens skulle betyda!) Om du behöver validera unikhet relaterad till en ManyToManyField, försök använda en signal eller en explicit through modell.

Det ValidationError som uppstår vid modellvalidering när villkoret överträds har felkoden unique_together.

begränsningarLink to this heading#

Options.constraintsLink to this definition#

En lista över begränsningar som du vill definiera på modellen:

Code

from django.db import models


class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
        ]

verbose_namnLink to this heading#

Options.verbose_nameLink to this definition#

Ett mänskligt läsbart namn för objektet, singular:

Code

verbose_name = "pizza"

Om detta inte anges kommer Django att använda en sammansatt version av klassnamnet: CamelCase blir camel case.

verbose_namn_pluralLink to this heading#

Options.verbose_name_pluralLink to this definition#

Det plurala namnet för objektet:

Code

verbose_name_plural = "stories"

Om detta inte anges kommer Django att använda verbose_name + "s".

etikettLink to this heading#

Options.labelLink to this definition#

Representation av objektet, returnerar app_label.object_name, t.ex. 'polls.Question'.

etikett_nedreLink to this heading#

Options.label_lowerLink to this definition#

Representation av modellen, returnerar app_label.model_name, t.ex. 'polls.question'.