---
title: "Alternativ för modell Meta"
version: 5.2
locale: sv
source: https://docs.djangoproject.com/sv/5.2/ref/models/options/
canonical: https://djangodocs.dev/sv/5.2/ref/models/options/
---
# Alternativ för modell `Meta`

Detta dokument förklarar alla möjliga [metadata options](/sv/5.2/topics/db/models/#meta-options) som du kan ge din modell i dess interna `class Meta`.

## Tillgängliga `Meta`-alternativ

### `abstrakt`

#### `Options.abstract`

Om `abstract = True`, kommer denna modell att vara en [abstrakt basklass](/sv/5.2/topics/db/models/#abstract-base-classes).

### `app_label`

#### `Options.app_label`

Om en modell definieras utanför en applikation i [`INSTALLED_APPS`](/sv/5.2/ref/settings/#std-setting-INSTALLED_APPS), måste den ange vilken app den tillhör:

```
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_chefsnamn`

#### `Options.base_manager_name`

Attributnamnet på hanteraren, t.ex. `'objects'`, som ska användas för modellens [`_base_manager`](/sv/5.2/topics/db/managers/#django.db.models.Model._base_manager).

### `db_table`

#### `Options.db_table`

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

```
db_table = "music_album"
```

#### Tabellnamn

För att spara tid härleder Django automatiskt namnet på databastabellen från namnet på din modellklass och den app som innehåller den. Namnet på en modells databastabell konstrueras genom att modellens ”app label” - det namn du använde i [`manage.py startapp`](/sv/5.2/ref/django-admin/#django-admin-startapp) \- kopplas till modellens klassnamn, med ett understreck mellan dem.

Om du t.ex. har en app `bookstore` (som skapats av `manage.py startapp bookstore`), kommer en modell som definieras som `class Book` att ha en databastabell med namnet `bookstore_book`.

Om du vill åsidosätta databasens tabellnamn använder du parametern `db_table` i `class Meta`.

Om tabellnamnet 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.

> **Använd tabellnamn med små bokstäver för MariaDB och MySQL**
>
> Det rekommenderas starkt att du använder tabellnamn med gemener när du åsidosätter tabellnamnet via `db_table`, särskilt om du använder MySQL-backend. Se [MySQL notes](/sv/5.2/ref/databases/#mysql-notes) för mer information.

> **Tabellnamn som citeras för Oracle**
>
> För att uppfylla den begränsning på 30 tecken som Oracle har för tabellnamn och för att matcha de vanliga konventionerna för Oracle-databaser kan Django förkorta tabellnamn och göra dem till versaler. För att förhindra sådana omvandlingar, använd ett citerat namn som värde för `db_table`:
>
> ```
> db_table = '"name_left_in_lowercase"'
> ```
>
> Sådana citerade namn kan också användas med Djangos andra stödda databasbackends; med undantag för Oracle har citaten dock ingen effekt. Se [Oracle notes](/sv/5.2/ref/databases/#oracle-notes) för mer information.

### `db_table_comment`

#### `Options.db_table_comment`

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_tablespace`

#### `Options.db_tablespace`

Namnet på det [databas-tabellutrymme](/sv/5.2/topics/db/tablespaces/) som ska användas för den här modellen. Standardvärdet är projektets [`DEFAULT_TABLESPACE`](/sv/5.2/ref/settings/#std-setting-DEFAULT_TABLESPACE)-inställning, om den är inställd. Om backend inte stöder tablespaces ignoreras detta alternativ.

### `förvaltarens_namn`

#### `Options.default_manager_name`

Namnet på den manager som ska användas för modellens [`_default_manager`](/sv/5.2/topics/db/managers/#django.db.models.Model._default_manager).

### `förvaltat_relaterat_namn`

#### `Options.default_related_name`

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`](/sv/5.2/ref/models/fields/#django.db.models.ForeignKey.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](/sv/5.2/topics/db/models/#abstract-related-name).

### ”Hämta senaste by

#### `Options.get_latest_by`

Namnet på ett fält eller en lista med fältnamn i modellen, vanligtvis [`DateField`](/sv/5.2/ref/models/fields/#django.db.models.DateField), [`DateTimeField`](/sv/5.2/ref/models/fields/#django.db.models.DateTimeField) eller [`IntegerField`](/sv/5.2/ref/models/fields/#django.db.models.IntegerField). Detta anger det eller de standardfält som ska användas i din modell [`Manager`](/sv/5.2/topics/db/managers/#django.db.models.Manager):s metoder [`latest()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.latest) och [`earliest()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.earliest).

Exempel:

```
# 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()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.latest)-dokumenten för mer information.

### `hanterad`

#### `Options.managed`

Standardvärdet är `True`, vilket innebär att Django kommer att skapa lämpliga databastabeller i [`migrate`](/sv/5.2/ref/django-admin/#django-admin-migrate) eller som en del av migreringar och ta bort dem som en del av ett [`flush`](/sv/5.2/ref/django-admin/#django-admin-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`](/sv/5.2/ref/models/fields/#django.db.models.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`](/sv/5.2/ref/models/fields/#django.db.models.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](/sv/5.2/topics/db/models/#proxy-models).

### ”ordning\_med\_respekt\_för

#### `Options.order_with_respect_to`

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:

```
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:

```pycon
>>> 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:

```pycon
>>> 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`:

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

> **order_with_respect_to ställer implicit in alternativet ordering**
>
> Internt lägger `order_with_respect_to` till ett extra fält/databaskolumn med namnet `_order` och sätter modellens [`ordering`](#django.db.models.Options.ordering)-alternativ till detta fält. Följaktligen kan inte `order_with_respect_to` och `ordering` användas tillsammans, och den ordning som läggs till av `order_with_respect_to` kommer att gälla när du hämtar en lista med objekt av denna modell.

> **Ändra order_med_respekt_för**
>
> Eftersom `order_with_respect_to` lägger till en ny databaskolumn måste du se till att göra och tillämpa lämpliga migreringar om du lägger till eller ändrar `order_with_respect_to` efter din första [`migrate`](/sv/5.2/ref/django-admin/#django-admin-migrate).

### `beställning`

#### `Options.ordering`

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

```
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:

```
ordering = ["pub_date"]
```

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

```
ordering = ["-pub_date"]
```

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

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

Du kan också använda [frågeuttryck](/sv/5.2/ref/models/expressions/). För att sortera efter `author` stigande och få null-värden att sorteras sist, använd detta:

```
from django.db.models import F

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

> **Default ordering and GROUP BY**
>
> In [GROUP BY queries](/sv/5.2/topics/db/aggregation/#aggregation-ordering-interaction) (for example,
> those using [`values()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.values) and [`annotate()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.annotate)), the
> default ordering is not applied.

> **Warning**
>
> Beställning är inte en gratis operation. Varje fält som du lägger till i beställningen medför en kostnad för din databas. Varje främmande nyckel som du lägger till kommer implicit att inkludera alla sina standardbeställningar också.
>
> Om en fråga inte har någon angiven ordning returneras resultaten från databasen i en ospecificerad ordning. En viss ordning garanteras endast när ordningen görs med hjälp av en uppsättning fält som unikt identifierar varje objekt i resultatet. Om t.ex. fältet `name` inte är unikt garanterar inte beställningen efter det att objekt med samma namn alltid visas i samma ordning.

### `behörigheter`

#### `Options.permissions`

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`:

```
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örigheter`

#### `Options.default_permissions`

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`](/sv/5.2/ref/django-admin/#django-admin-migrate) för att förhindra att utelämnade behörigheter skapas.

### `proxy`

#### `Options.proxy`

Om `proxy = True`, kommer en modell som subklassar en annan modell att behandlas som en [proxymodell](/sv/5.2/topics/db/models/#proxy-models).

### `krävda_db_funktioner`

#### `Options.required_db_features`

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ör`

#### `Options.required_db_vendor`

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_sparande`

#### `Options.select_on_save`

Bestämmer om Django ska använda pre-1.6 [`django.db.models.Model.save()`](/sv/5.2/ref/models/instances/#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()`](/sv/5.2/ref/models/instances/#django.db.models.Model.save) för mer information om den gamla och nya sparalgoritmen.

### `index`

#### `Options.indexes`

En lista över [index](/sv/5.2/ref/models/indexes/) som du vill definiera på modellen:

```
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_together`

#### `Options.unique_together`

> **Använd istället UniqueConstraint med alternativet constraints.**
>
> [`UniqueConstraint`](/sv/5.2/ref/models/constraints/#django.db.models.UniqueConstraint) erbjuder mer funktionalitet än `unique_together`. `unique_together` kan vara föråldrad i framtiden.

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

```
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:

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

En [`ManyToManyField`](/sv/5.2/ref/models/fields/#django.db.models.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`](/sv/5.2/ref/models/fields/#django.db.models.ManyToManyField), försök använda en signal eller en explicit [`through`](/sv/5.2/ref/models/fields/#django.db.models.ManyToManyField.through) modell.

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

### `begränsningar`

#### `Options.constraints`

En lista över [begränsningar](/sv/5.2/ref/models/constraints/) som du vill definiera på modellen:

```
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_namn`

#### `Options.verbose_name`

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

```
verbose_name = "pizza"
```

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

### `verbose_namn_plural`

#### `Options.verbose_name_plural`

Det plurala namnet för objektet:

```
verbose_name_plural = "stories"
```

Om detta inte anges kommer Django att använda [`verbose_name`](#django.db.models.Options.verbose_name) \+ `"s"`.

## Skrivskyddade `Meta`-attribut

### `etikett`

#### `Options.label`

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

### `etikett_nedre`

#### `Options.label_lower`

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