---
title: "Referens till modellinstans"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/ref/models/instances/
canonical: https://djangodocs.dev/sv/6.1/ref/models/instances/
---
# Referens till modellinstans

Detta dokument beskriver detaljerna i API:et `Model`. Det bygger på det material som presenteras i guiderna [model](/sv/6.1/topics/db/models/) och [database query](/sv/6.1/topics/db/queries/), så du vill förmodligen läsa och förstå dessa dokument innan du läser det här.

I den här referensen använder vi [exempel på bloggmodeller](/sv/6.1/topics/db/queries/#queryset-model-example) som presenteras i [guide för databasfrågor](/sv/6.1/topics/db/queries/).

## Skapa objekt

För att skapa en ny instans av en modell instansierar du den som vilken annan Python-klass som helst:

#### `class Model(**kwargs)`

The keyword arguments are the names of the fields you’ve defined on your model.
Note that instantiating a model in no way touches your database; for that, you
need to [`save()`](#django.db.models.Model.save).

> **Note**
>
> You may be tempted to customize the model by overriding the `__init__`
> method. If you do so, however, take care not to change the calling
> signature as any change may prevent the model instance from being saved.
> Additionally, referring to model fields within `__init__` may potentially
> result in infinite recursion errors in some circumstances. Rather than
> overriding `__init__`, try using one of these approaches:
>
> 1. Lägg till en classmethod på modellklassen:
>
>    ```
>    from django.db import models
>
>
>    class Book(models.Model):
>        title = models.CharField(max_length=100)
>
>        @classmethod
>        def create(cls, title):
>            book = cls(title=title)
>            # do something with the book
>            return book
>
>
>    book = Book.create("Pride and Prejudice")
>    ```
> 2. Lägg till en metod på en anpassad manager (vanligtvis att föredra):
>
>    ```
>    class BookManager(models.Manager):
>        def create_book(self, title):
>            book = self.create(title=title)
>            # do something with the book
>            return book
>
>
>    class Book(models.Model):
>        title = models.CharField(max_length=100)
>
>        objects = BookManager()
>
>
>    book = Book.objects.create_book("Pride and Prejudice")
>    ```

> **Setting attributes does not convert types**
>
> Setting a model attribute does not convert the value to the field’s Python
> type. That conversion happens when the model is [validated](#validating-objects). Although a field assigned a value of a different
> type (for example, a string assigned to a
> [`UUIDField`](/sv/6.1/ref/models/fields/#django.db.models.UUIDField)) may be converted when
> [`save()`](#django.db.models.Model.save) executes a query, the in-memory instance will keep the
> original value until it is [reloaded](#refreshing-objects).

### Anpassning av modellbelastning

#### `classmethod Model.from_db(db, field_names, values)`

Metoden `from_db()` kan användas för att anpassa skapandet av modellinstanser vid laddning från databasen.

Argumentet `db` innehåller databasaliaset för den databas som modellen laddas från, `field_names` innehåller namnen på alla inlästa fält och `values` innehåller de inlästa värdena för varje fält i `field_names`. `field_names` är i samma ordning som `values`. Om alla modellens fält finns med, kommer `values` garanterat att finnas i den ordning som `__init__()` förväntar sig dem. Det vill säga, instansen kan skapas av `cls(*values)`. Om några fält är uppskjutna kommer de inte att visas i `field_names`. Tilldela i så fall ett värde av `django.db.models.DEFERRED` till vart och ett av de saknade fälten.

Förutom att skapa den nya modellen måste metoden `from_db()` ställa in flaggorna `adding` och `db` i den nya instansens attribut [`_state`](#django.db.models.Model._state).

Nedan följer ett exempel som visar hur man registrerar de ursprungliga värdena för fält som laddas från databasen:

```
from django.db.models import DEFERRED

@classmethod
def from_db(cls, db, field_names, values):
    # Default implementation of from_db() (subject to change and could
    # be replaced with super()).
    if len(values) != len(cls._meta.concrete_fields):
        values = list(values)
        values.reverse()
        values = [
            values.pop() if f.attname in field_names else DEFERRED
            for f in cls._meta.concrete_fields
        ]
    instance = cls(*values)
    instance._state.adding = False
    instance._state.db = db
    # customization to store the original field values on the instance
    instance._loaded_values = dict(
        zip(field_names, (value for value in values if value is not DEFERRED))
    )
    return instance

def save(self, **kwargs):
    # Check how the current values differ from ._loaded_values. For example,
    # prevent changing the creator_id of the model. (This example doesn't
    # support cases where 'creator_id' is deferred).
    if not self._state.adding and (
        self.creator_id != self._loaded_values["creator_id"]
    ):
        raise ValueError("Updating the value of creator isn't allowed")
    super().save(**kwargs)
```

Exemplet ovan visar en fullständig `from_db()`-implementering för att klargöra hur det görs. I det här fallet skulle det vara möjligt att använda ett `super()`-anrop i `from_db()`-metoden.

## Uppdatering av objekt från databas

Om du tar bort ett fält från en modellinstans laddas värdet från databasen när du öppnar det igen:

```pycon
>>> obj = MyModel.objects.first()
>>> del obj.field
>>> obj.field  # Loads the field from the database
```

#### `Model.refresh_from_db(using=None, fields=None, from_queryset=None)`

#### `Model.arefresh_from_db(using=None, fields=None, from_queryset=None)`

*Asynkron version*: `arefresh_from_db()`

Om du behöver ladda om en modells värden från databasen kan du använda metoden `refresh_from_db()`. När denna metod anropas utan argument görs följande:

1. Alla icke uppskjutna fält i modellen uppdateras till de värden som för närvarande finns i databasen.
2. Alla cachelagrade relationer rensas från den omladdade instansen.

Endast modellens fält laddas om från databasen. Andra databasberoende värden som t.ex. annoteringar laddas inte om. Eventuella [`@cached_property`](/sv/6.1/ref/utils/#django.utils.functional.cached_property)-attribut rensas inte heller.

Omladdningen sker från den databas som instansen laddades från, eller från standarddatabasen om instansen inte laddades från databasen. Argumentet `using` kan användas för att tvinga fram den databas som används för omlastning.

Det är möjligt att tvinga fram en uppsättning fält som ska laddas genom att använda argumentet `fields`.

Om du till exempel vill testa att ett anrop av `update()` resulterar i den förväntade uppdateringen, kan du skriva ett test som liknar detta:

```
def test_update_result(self):
    obj = MyModel.objects.create(val=1)
    MyModel.objects.filter(pk=obj.pk).update(val=F("val") + 1)
    # At this point obj.val is still 1, but the value in the database
    # was updated to 2. The object's updated value needs to be reloaded
    # from the database.
    obj.refresh_from_db()
    self.assertEqual(obj.val, 2)
```

When a deferred field is loaded on-demand for a single model instance, the
loading happens through this method. Thus it is possible to customize the way
this loading happens. The example below shows how one can reload all of the
instance’s fields when a deferred field is loaded on-demand:

```
class ExampleModel(models.Model):
    def refresh_from_db(self, using=None, fields=None, **kwargs):
        # fields contains the name of the deferred field to be
        # loaded.
        if fields is not None:
            fields = set(fields)
            deferred_fields = self.get_deferred_fields()
            # If any deferred field is going to be loaded
            if fields.intersection(deferred_fields):
                # then load all of them
                fields = fields.union(deferred_fields)
        super().refresh_from_db(using, fields, **kwargs)
```

Argumentet `from_queryset` gör det möjligt att använda en annan queryset än den som skapats från [`_base_manager`](/sv/6.1/topics/db/managers/#django.db.models.Model._base_manager). Det ger dig mer kontroll över hur modellen laddas om. Till exempel:, när din modell använder soft deletion kan du göra `refresh_from_db()` för att ta hänsyn till detta:

```
obj.refresh_from_db(from_queryset=MyModel.active_objects.all())
```

Du kan cacha relaterade objekt som annars skulle rensas bort från den omladdade instansen:

```
obj.refresh_from_db(from_queryset=MyModel.objects.select_related("related_field"))
```

Du kan låsa raden till slutet av transaktionen innan du laddar om en modells värden:

```
obj.refresh_from_db(from_queryset=MyModel.objects.select_for_update())
```

#### `Model.get_deferred_fields()`

En hjälpmetod som returnerar en uppsättning som innehåller attributnamnen för alla de fält som för närvarande är uppskjutna för denna modell.

## Validering av objekt

Det finns fyra steg i valideringen av en modell:

1. Validate the model fields - [`Model.clean_fields()`](#django.db.models.Model.clean_fields)
2. Validate the model as a whole - [`Model.clean()`](#django.db.models.Model.clean)
3. Validate the field uniqueness - [`Model.validate_unique()`](#django.db.models.Model.validate_unique)
4. Validera begränsningarna - [`Model.validate_constraints()`](#django.db.models.Model.validate_constraints)

Alla fyra stegen utförs när du anropar en modells [`full_clean()`](#django.db.models.Model.full_clean)-metod.

When you use a [`ModelForm`](/sv/6.1/topics/forms/modelforms/#django.forms.ModelForm), the call to
[`is_valid()`](/sv/6.1/ref/forms/api/#django.forms.Form.is_valid) will perform these validation steps for
all the fields that are included on the form. See the [ModelForm
documentation](/sv/6.1/topics/forms/modelforms/) for more information. You should only
need to call a model’s [`full_clean()`](#django.db.models.Model.full_clean) method if you plan to handle
validation errors yourself, or if you have excluded fields from the
[`ModelForm`](/sv/6.1/topics/forms/modelforms/#django.forms.ModelForm) that require validation.

#### `Model.full_clean(exclude=None, validate_unique=True, validate_constraints=True)`

This method calls [`Model.clean_fields()`](#django.db.models.Model.clean_fields), [`Model.clean()`](#django.db.models.Model.clean),
[`Model.validate_unique()`](#django.db.models.Model.validate_unique) (if `validate_unique` is `True`),  and
[`Model.validate_constraints()`](#django.db.models.Model.validate_constraints) (if `validate_constraints` is `True`)
in that order and raises a [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) that
has a `message_dict` attribute containing errors from all four stages.

Det valfria argumentet `exclude` kan användas för att tillhandahålla en `uppsättning` av fältnamn som kan uteslutas från validering och rengöring. [`ModelForm`](/sv/6.1/topics/forms/modelforms/#django.forms.ModelForm) använder detta argument för att utesluta fält som inte finns i ditt formulär från att valideras eftersom eventuella fel som uppstår inte kan korrigeras av användaren.

Note that `full_clean()` will *not* be called automatically when you call
your model’s [`save()`](#django.db.models.Model.save) method. You’ll need to call it manually
when you want to run one-step model validation for your own manually created
models. For example:

```
from django.core.exceptions import ValidationError

try:
    article.full_clean()
except ValidationError as e:
    # Do something based on the errors contained in e.message_dict.
    # Display them to a user, or handle them programmatically.
    pass
```

Det första steget som `full_clean()` utför är att rengöra varje enskilt fält.

#### `Model.clean_fields(exclude=None)`

Denna metod validerar alla fält i din modell. Det valfria `exclude` argumentet låter dig tillhandahålla en `uppsättning` av fältnamn som ska uteslutas från validering. Det kommer att ge upphov till en [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) om några fält misslyckas med valideringen.

The second step `full_clean()` performs is to call [`Model.clean()`](#django.db.models.Model.clean).
This method should be overridden to perform custom validation on your model.

#### `Model.clean()`

Den här metoden bör användas för att tillhandahålla anpassad modellvalidering och för att ändra attribut på din modell om så önskas. Du kan t.ex. använda den för att automatiskt ange ett värde för ett fält eller för att göra en validering som kräver åtkomst till mer än ett enda fält:

```
import datetime
from django.core.exceptions import ValidationError
from django.db import models
from django.utils.translation import gettext_lazy as _

class Article(models.Model):
    ...

    def clean(self):
        # Don't allow draft entries to have a pub_date.
        if self.status == "draft" and self.pub_date is not None:
            raise ValidationError(_("Draft entries may not have a publication date."))
        # Set the pub_date for published items if it hasn't been set already.
        if self.status == "published" and self.pub_date is None:
            self.pub_date = datetime.date.today()
```

Note, however, that like [`Model.full_clean()`](#django.db.models.Model.full_clean), a model’s `clean()`
method is not invoked when you call your model’s [`save()`](#django.db.models.Model.save) method.

I exemplet ovan instantierades undantaget [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) av `Model.clean()` med en sträng, så det kommer att lagras i en speciell felordboksnyckel, [`NON_FIELD_ERRORS`](/sv/6.1/ref/exceptions/#django.core.exceptions.NON_FIELD_ERRORS). Den här nyckeln används för fel som är knutna till hela modellen istället för till ett specifikt fält:

```
from django.core.exceptions import NON_FIELD_ERRORS, ValidationError

try:
    article.full_clean()
except ValidationError as e:
    non_field_errors = e.message_dict[NON_FIELD_ERRORS]
```

För att tilldela undantag till ett specifikt fält, instansiera [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) med en ordbok, där nycklarna är fältnamnen. Vi kan uppdatera det föregående exemplet för att tilldela felet till fältet `pub_date`:

```
class Article(models.Model):
    ...

    def clean(self):
        # Don't allow draft entries to have a pub_date.
        if self.status == "draft" and self.pub_date is not None:
            raise ValidationError(
                {"pub_date": _("Draft entries may not have a publication date.")}
            )
        ...
```

Om du upptäcker fel i flera fält under `Model.clean()` kan du också skicka en ordlista som mappar fältnamn till errors:

```
raise ValidationError(
    {
        "title": ValidationError(_("Missing title."), code="required"),
        "pub_date": ValidationError(_("Invalid date."), code="invalid"),
    }
)
```

Sedan kommer `full_clean()` att kontrollera unika begränsningar för din modell.

> **Så här skapar du fältspecifika valideringsfel om dessa fält inte visas i ett ModelForm**
>
> Du kan inte skapa valideringsfel i `Model.clean()` för fält som inte visas i ett modellformulär (ett formulär kan begränsa sina fält med hjälp av `Meta.fields` eller `Meta.exclude`). Om du gör det kommer ett `ValueError` att uppstå eftersom valideringsfelet inte kommer att kunna associeras med det uteslutna fältet.
>
> För att komma runt detta dilemma, åsidosätt istället [`Model.clean_fields()`](#django.db.models.Model.clean_fields) eftersom den tar emot listan över fält som är undantagna från validering. Till exempel:
>
> ```
> class Article(models.Model):
>     ...
>
>     def clean_fields(self, exclude=None):
>         super().clean_fields(exclude=exclude)
>         if self.status == "draft" and self.pub_date is not None:
>             if exclude and "status" in exclude:
>                 raise ValidationError(
>                     _("Draft entries may not have a publication date.")
>                 )
>             else:
>                 raise ValidationError(
>                     {
>                         "status": _(
>                             "Set status to draft if there is not a publication date."
>                         ),
>                     }
>                 )
> ```

#### `Model.validate_unique(exclude=None)`

Denna metod liknar [`clean_fields()`](#django.db.models.Model.clean_fields), men validerar unikhetsbegränsningar som definieras via [`Field.unique`](/sv/6.1/ref/models/fields/#django.db.models.Field.unique), [`Field.unique_for_date`](/sv/6.1/ref/models/fields/#django.db.models.Field.unique_for_date), [`Field.unique_for_month`](/sv/6.1/ref/models/fields/#django.db.models.Field.unique_for_month), [`Field.unique_for_year`](/sv/6.1/ref/models/fields/#django.db.models.Field.unique_for_year) eller [`Meta.unique_together`](/sv/6.1/ref/models/options/#django.db.models.Options.unique_together) på din modell istället för enskilda fältvärden. Det valfria argumentet `exclude` låter dig tillhandahålla en `uppsättning` av fältnamn som ska uteslutas från validering. Det kommer att ge upphov till en [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) om några fält misslyckas med valideringen.

[`UniqueConstraint`](/sv/6.1/ref/models/constraints/#django.db.models.UniqueConstraint)s som definieras i [`Meta.constraints`](/sv/6.1/ref/models/options/#django.db.models.Options.constraints) valideras av [`Model.validate_constraints()`](#django.db.models.Model.validate_constraints).

Observera att om du anger ett `exclude`-argument till `validate_unique()`, kommer alla [`unique_together`](/sv/6.1/ref/models/options/#django.db.models.Options.unique_together)-begränsningar som involverar ett av de fält du angav inte att kontrolleras.

Slutligen kommer `full_clean()` att kontrollera eventuella andra begränsningar för din modell.

#### `Model.validate_constraints(exclude=None)`

Denna metod validerar alla begränsningar som definieras i [`Meta.constraints`](/sv/6.1/ref/models/options/#django.db.models.Options.constraints). Det valfria `exclude`-argumentet låter dig tillhandahålla en `uppsättning` av fältnamn som ska uteslutas från validering. Det kommer att ge upphov till en [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) om några begränsningar misslyckas med valideringen.

## Spara objekt

För att spara ett objekt tillbaka till databasen, anropa `save()`:

#### `Model.save(* (Keyword-only parameters separator (PEP 3102)), force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None)`

#### `Model.asave(* (Keyword-only parameters separator (PEP 3102)), force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None)`

*Asynkron version*: `asave()`

Mer information om hur du använder argumenten `force_insert` och `force_update` finns i [Tvinga fram en INSERT eller UPDATE](#ref-models-force-insert). Detaljer om argumentet `update_fields` finns i avsnittet [Ange vilka fält som ska sparas](#ref-models-update-fields).

Om du vill ha ett anpassat sparbeteende kan du åsidosätta denna metod `save()`. Se [Åsidosätta fördefinierade modellmetoder](/sv/6.1/topics/db/models/#overriding-model-methods) för mer information.

Processen för att spara modeller har också vissa finesser; se avsnitten nedan.

### Automatiskt ökande primärnycklar

Om en modell har en [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField) \- en automatiskt ökande primärnyckel - kommer det automatiskt ökande värdet att beräknas och sparas som ett attribut på ditt objekt första gången du anropar `save()`:

```pycon
>>> b2 = Blog(name="Cheddar Talk", tagline="Thoughts on cheese.")
>>> b2.id  # Returns None, because b2 doesn't have an ID yet.
>>> b2.save()
>>> b2.id  # Returns the ID of your new object.
```

Det finns inget sätt att säga vad värdet på ett ID kommer att vara innan du anropar `save()`, eftersom det värdet beräknas av din databas, inte av Django.

För enkelhetens skull har varje modell en [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField) med namnet `id` som standard om du inte uttryckligen anger `primary_key=True` på ett fält i din modell. Se dokumentationen för [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField) för mer information.

#### Egenskapen ”pk

#### `Model.pk`

Oavsett om du definierar ett primärnyckelfält själv, eller låter Django leverera ett åt dig, kommer varje modell att ha en egenskap som heter `pk`. Den beter sig som ett vanligt attribut på modellen, men är faktiskt ett alias för vilket fält eller fält som utgör primärnyckeln för modellen. Du kan läsa och ställa in det här värdet, precis som du skulle göra för vilket annat attribut som helst, och det kommer att uppdatera rätt fält i modellen.

#### Explicit specificering av värden för auto-primary-key

Om en modell har en [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField) men du vill definiera ett nytt objekts ID uttryckligen när du sparar, definierar du det uttryckligen innan du sparar, i stället för att förlita dig på den automatiska tilldelningen av ID:

```pycon
>>> b3 = Blog(id=3, name="Cheddar Talk", tagline="Thoughts on cheese.")
>>> b3.id  # Returns 3.
>>> b3.save()
>>> b3.id  # Returns 3.
```

Om du tilldelar auto-primary-key-värden manuellt, se till att inte använda ett redan existerande primary-key-värde! Om du skapar ett nytt objekt med ett explicit primary-key-värde som redan finns i databasen, kommer Django att anta att du ändrar den befintliga posten snarare än att skapa en ny.

Med tanke på bloggexemplet ”Cheddar Talk” ovan skulle detta exempel åsidosätta den föregående posten i databasen:

```
b4 = Blog(id=3, name="Not Cheddar", tagline="Anything but cheese.")
b4.save()  # Overrides the previous blog with ID=3!
```

Se [Hur Django vet att UPDATE vs. INSERT](#how-django-knows-to-update-vs-insert), nedan, för anledningen till att detta händer.

Att uttryckligen ange värden för automatisk primärnyckel är mest användbart för masslagring av objekt, när du är säker på att du inte kommer att få kollisioner mellan primärnycklar.

Om du använder PostgreSQL kan sekvensen som är associerad med den primära nyckeln behöva uppdateras; se [Manuellt specificerade värden för primärnycklar med automatisk inkrementering](/sv/6.1/ref/databases/#manually-specified-autoincrement-pk).

### Vad händer när du sparar?

När du sparar ett objekt utför Django följande steg:

1. Sänd en signal före sparande [`pre_save`](/sv/6.1/ref/signals/#django.db.models.signals.pre_save)-signalen skickas, vilket gör att alla funktioner som lyssnar på den signalen kan göra något.
2. Varje fälts metod [`pre_save()`](/sv/6.1/ref/models/fields/#django.db.models.Field.pre_save) anropas för att utföra alla automatiserade datamodifieringar som behövs. Till exempel: åsidosätter datum-/tidsfälten `pre_save()` för att implementera [`auto_now_add`](/sv/6.1/ref/models/fields/#django.db.models.DateField.auto_now_add) och [`auto_now`](/sv/6.1/ref/models/fields/#django.db.models.DateField.auto_now).
3. Varje fälts [`get_db_prep_save()`](/sv/6.1/ref/models/fields/#django.db.models.Field.get_db_prep_save)-metod ombeds att tillhandahålla sitt aktuella värde i en datatyp som kan skrivas till databasen.

   De flesta fält kräver ingen dataförberedelse. Enkla datatyper, t.ex. heltal och strängar, är ”skrivklara” som Python-objekt. Mer komplexa datatyper kräver dock ofta viss modifiering.

   Till exempel: använder [`DateField`](/sv/6.1/ref/models/fields/#django.db.models.DateField)-fält ett Python-objekt med `datetime` för att lagra data. Databaser lagrar inte `datetime`-objekt, så fältvärdet måste konverteras till en ISO-kompatibel datumsträng för att infogas i databasen.
4. De förbehandlade, förberedda uppgifterna sammanställs till en SQL-sats för inmatning i databasen.
5. Skicka en post-save-signal [`post_save`](/sv/6.1/ref/signals/#django.db.models.signals.post_save)-signalen skickas, vilket gör att alla funktioner som lyssnar på den signalen kan göra något.

### Hur Django vet att UPDATE vs. INSERT

Du kanske har märkt att Djangos databasobjekt använder samma `save()`-metod för att skapa och ändra objekt. Django abstraherar behovet av att använda `INSERT` eller `UPDATE` SQL-satser. När du anropar `save()` och objektets primära nyckelattribut **inte** definierar en [`default`](/sv/6.1/ref/models/fields/#django.db.models.Field.default) eller [`db_default`](/sv/6.1/ref/models/fields/#django.db.models.Field.db_default), följer Django denna algoritm:

- Om objektets primära nyckelattribut är inställt på något annat än `None`, utför Django en `UPDATE`.
- Om objektets primärnyckelattribut *inte* är inställt eller om `UPDATE` inte uppdaterade någonting (t.ex. om primärnyckeln är inställd på ett värde som inte finns i databasen), utför Django en `INSERT`.

Om objektets primära nyckelattribut definierar en [`default`](/sv/6.1/ref/models/fields/#django.db.models.Field.default) eller [`db_default`](/sv/6.1/ref/models/fields/#django.db.models.Field.db_default) så utför Django en `UPDATE` om det är en befintlig modellinstans och den primära nyckeln är inställd på ett värde som finns i databasen. Annars utför Django en `INSERT`.

Det enda problemet här är att du bör vara försiktig så att du inte uttryckligen anger ett primärnyckelvärde när du sparar nya objekt, om du inte kan garantera att primärnyckelvärdet är oanvänt. För mer information om denna nyans, se [Explicit specificering av auto-primary-key-värden](#explicitly-specifying-auto-primary-key-values) ovan och [Tvinga fram en INSERT eller UPDATE](#forcing-an-insert-or-update) nedan.

I Django 1.5 och tidigare gjorde Django en `SELECT` när primärnyckelattributet var inställt. Om `SELECT` hittade en rad, gjorde Django en `UPDATE`, annars gjorde den en `INSERT`. Den gamla algoritmen resulterar i ytterligare en fråga i fallet `UPDATE`. Det finns några sällsynta fall där databasen inte rapporterar att en rad uppdaterades även om databasen innehåller en rad för objektets primära nyckelvärde. Ett exempel är PostgreSQL `ON UPDATE` trigger som returnerar `NULL`. I sådana fall är det möjligt att återgå till den gamla algoritmen genom att ställa in alternativet [`select_on_save`](/sv/6.1/ref/models/options/#django.db.models.Options.select_on_save) till `True`.

#### Tvinga fram en INSERT eller UPDATE

In some rare circumstances, it’s necessary to be able to force the
[`save()`](#django.db.models.Model.save) method to perform an SQL `INSERT` and not fall back to
doing an `UPDATE`. Or vice-versa: update, if possible, but not insert a new
row. In these cases you can pass the `force_insert=True` or
`force_update=True` parameters to the [`save()`](#django.db.models.Model.save) method.
Passing both parameters is an error: you cannot both insert *and* update at the
same time!

När du använder [multi-table inheritance](/sv/6.1/topics/db/models/#multi-table-inheritance) är det också möjligt att tillhandahålla en tupel av överordnade klasser till `force_insert` för att tvinga fram `INSERT`-satser för varje bas. Till exempel:

```
Restaurant(pk=1, name="Bob's Cafe").save(force_insert=(Place,))

Restaurant(pk=1, name="Bob's Cafe", rating=4).save(force_insert=(Place, Rating))
```

Du kan skicka `force_insert=(models.Model,)` för att tvinga fram en `INSERT`-sats för alla föräldrar. Som standard tvingar `force_insert=True` bara fram en ny rad för den aktuella modellen.

> **Changed in Django 6.0**
>
> When a forced update does not affect any rows a
> [`NotUpdated`](/sv/6.1/ref/models/class/#django.db.models.Model.NotUpdated) exception is raised. On previous
> versions a generic [`django.db.DatabaseError`](/sv/6.1/ref/exceptions/#django.db.DatabaseError) was raised.

Det bör vara mycket sällsynt att du behöver använda dessa parametrar. Django kommer nästan alltid att göra det rätta och att försöka åsidosätta det kommer att leda till fel som är svåra att spåra. Denna funktion är endast avsedd för avancerad användning.

Om du använder `update_fields` kommer du att tvinga fram en uppdatering på samma sätt som `force_update`.

### Uppdatering av attribut baserat på befintliga fält

Ibland behöver du utföra en enkel aritmetisk uppgift på ett fält, till exempel att öka eller minska det aktuella värdet. Ett sätt att uppnå detta är att göra aritmetiken i Python som:

```pycon
>>> product = Product.objects.get(name="Venezuelan Beaver Cheese")
>>> product.number_sold += 1
>>> product.save()
```

Om det gamla värdet för `number_sold` som hämtades från databasen var 10, kommer värdet 11 att skrivas tillbaka till databasen.

The process can be made robust, [avoiding a race condition](/sv/6.1/ref/models/expressions/#avoiding-race-conditions-using-f), as well as slightly faster by expressing
the update relative to the original field value, rather than as an explicit
assignment of a new value. Django provides [F()-uttryck](/sv/6.1/ref/models/expressions/#f-expressions) for performing
this kind of relative update. Using [F()-uttryck](/sv/6.1/ref/models/expressions/#f-expressions), the previous example
is expressed as:

```pycon
>>> from django.db.models import F
>>> product = Product.objects.get(name="Venezuelan Beaver Cheese")
>>> product.number_sold = F("number_sold") + 1
>>> product.save()
```

For more details, see the documentation on [F()-uttryck](/sv/6.1/ref/models/expressions/#f-expressions) and their
[use in update queries](/sv/6.1/topics/db/queries/#topics-db-queries-update).

### Ange vilka fält som ska sparas

Om `save()` får en lista med fältnamn i nyckelordsargumentet `update_fields`, kommer endast de fält som anges i listan att uppdateras. Detta kan vara önskvärt om du bara vill uppdatera ett eller ett fåtal fält på ett objekt. Det finns en liten prestandafördel med att förhindra att alla modellfält uppdateras i databasen. Till exempel:

```
product.name = "Name changed again"
product.save(update_fields=["name"])
```

Argumentet `update_fields` kan vara en iterabel som innehåller strängar. En tom `update_fields` iterabel hoppar över sparandet. Ett värde av `None` kommer att utföra en uppdatering på alla fält.

Om du anger `update_fields` kommer du att tvinga fram en uppdatering.

When saving a model fetched through deferred model loading
([`only()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.only) or
[`defer()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.defer)) only the fields loaded
from the DB will get updated. In effect there is an automatic
`update_fields` in this case. If you assign or change any deferred field
value, the field will be added to the updated fields.

> **Field.pre_save() och update_fields**
>
> Om `update_fields` skickas in anropas endast [`pre_save()`](/sv/6.1/ref/models/fields/#django.db.models.Field.pre_save)-metoderna i `update_fields`. Detta innebär till exempel att datum-/tidsfält med `auto_now=True` inte kommer att uppdateras om de inte ingår i `update_fields`.

## Radering av objekt

#### `Model.delete(using=DEFAULT_DB_ALIAS, keep_parents=False)`

#### `Model.adelete(using=DEFAULT_DB_ALIAS, keep_parents=False)`

*Asynkron version*: `adelete()`

Issues an SQL `DELETE` for the object. This only deletes the object in the
database; the Python instance will still exist and will still have data in
its fields, except for the primary key set to `None`. This method returns the
number of objects deleted and a dictionary with the number of deletions per
object type. The return value will count instances from related models if
Django is emulating cascade behavior via Python [`on_delete`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey.on_delete)
variants. Otherwise, for database variants such as
[`DB_CASCADE`](/sv/6.1/ref/models/fields/#django.db.models.DB_CASCADE), the return value will report only
instances of the [`QuerySet`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet)’s model.

Mer information, bland annat om hur du tar bort objekt i bulk, finns i [Radering av objekt](/sv/6.1/topics/db/queries/#topics-db-queries-delete).

Om du vill ha ett anpassat borttagningsbeteende kan du åsidosätta metoden `delete()`. Se [Åsidosätta fördefinierade modellmetoder](/sv/6.1/topics/db/models/#overriding-model-methods) för mer information.

Ibland med [multi-table inheritance](/sv/6.1/topics/db/models/#multi-table-inheritance) kan du vilja radera endast en underordnad modells data. Om du anger `keep_parents=True` behålls föräldramodellens data.

> **Changed in Django 6.1**
>
> Support for the `DB_*` variants of `on_delete` attribute was added.

## Betning av föremål

När du [`pickle`](https://docs.python.org/3/library/pickle.html#module-pickle) en modell, är dess nuvarande tillstånd pickled. När du plockar upp den kommer den att innehålla modellinstansen vid den tidpunkt då den plockades upp, snarare än de data som för närvarande finns i databasen.

> **Du kan inte dela pickles mellan versioner**
>
> Pickles av modeller är endast giltiga för den version av Django som användes för att generera dem. Om du genererar en pickle med Django version N, finns det ingen garanti för att pickle kommer att vara läsbar med Django version N+1. Pickles bör inte användas som en del av en långsiktig arkiveringsstrategi.
>
> Eftersom kompatibilitetsfel i pickle kan vara svåra att diagnostisera, t.ex. objekt som är korrupta i tysthet, skapas en `RuntimeWarning` när du försöker plocka upp en modell i en Django-version som är annorlunda än den där den plockades upp.

## Andra metoder för modellinstans

Några objektmetoder har speciella syften.

### `__str__()`

#### `Model.__str__()`

Metoden `__str__()` anropas när du anropar `str()` på ett objekt. Django använder `str(obj)` på ett antal ställen. Framför allt för att visa ett objekt på Django-adminsidan och som det värde som infogas i en mall när den visar ett objekt. Därför bör du alltid returnera en trevlig, mänskligt läsbar representation av modellen från metoden `__str__()`.

Till exempel:

```
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)

    def __str__(self):
        return f"{self.first_name} {self.last_name}"
```

### `__eq__()`

#### `Model.__eq__()`

Metoden equality är definierad så att instanser med samma primära nyckelvärde och samma konkreta klass anses vara lika, förutom att instanser med ett primärt nyckelvärde på `None` inte är lika med något annat än sig själva. För proxymodeller definieras den konkreta klassen som modellens första icke-proxyförälder; för alla andra modeller är det helt enkelt modellens klass.

Till exempel:

```
from django.db import models

class MyModel(models.Model):
    id = models.AutoField(primary_key=True)

class MyProxyModel(MyModel):
    class Meta:
        proxy = True

class MultitableInherited(MyModel):
    pass

# Primary keys compared
MyModel(id=1) == MyModel(id=1)
MyModel(id=1) != MyModel(id=2)
# Primary keys are None
MyModel(id=None) != MyModel(id=None)
# Same instance
instance = MyModel(id=None)
instance == instance
# Proxy model
MyModel(id=1) == MyProxyModel(id=1)
# Multi-table inheritance
MyModel(id=1) != MultitableInherited(id=1)
```

### `__hash__()`

#### `Model.__hash__()`

The `__hash__()` method is based on the instance’s primary key value. It
is effectively `hash(obj.pk)`. If the instance doesn’t have a primary key
value then a `TypeError` will be raised (otherwise the `__hash__()`
method would return different values before and after the instance is
saved), but changing the [`__hash__()`](https://docs.python.org/3/reference/datamodel.html#object.__hash__) value of an instance is
forbidden in Python.

### `get_absolute_url()`

#### `Model.get_absolute_url()`

Definiera en `get_absolute_url()`-metod för att tala om för Django hur man beräknar den kanoniska URL:en för ett objekt. För anropare bör denna metod se ut att returnera en sträng som kan användas för att hänvisa till objektet via HTTP.

Till exempel:

```
def get_absolute_url(self):
    return "/people/%i/" % self.id
```

While this code is correct and simple, it may not be the most portable way
to write this kind of method. The [`reverse()`](/sv/6.1/ref/urlresolvers/#django.urls.reverse) function is
usually the best approach.

Till exempel:

```
def get_absolute_url(self):
    from django.urls import reverse

    return reverse("people-detail", kwargs={"pk": self.pk})
```

En plats där Django använder `get_absolute_url()` är i admin-appen. Om ett objekt definierar den här metoden kommer objektredigeringssidan att ha en ”Visa på webbplatsen”-länk som hoppar direkt till objektets offentliga vy, som ges av `get_absolute_url()`.

På samma sätt använder ett par andra delar av Django, till exempel [syndication feed framework](/sv/6.1/ref/contrib/syndication/), `get_absolute_url()` när det är definierat. Om det är vettigt för din modells instanser att var och en har en unik URL, bör du definiera `get_absolute_url()`.

> **Warning**
>
> Du bör undvika att bygga URL:en från obekräftad användarinmatning, för att minska risken för förgiftning av länkar eller omdirigeringar:
>
> ```
> def get_absolute_url(self):
>     return "/%s/" % self.name
> ```
>
> Om `self.name` är `'/example.com'` returneras `'//example.com/'`, vilket i sin tur är en giltig schemarelativ URL men inte den förväntade `'/%2Fexample.com/'`.

It’s good practice to use `get_absolute_url()` in templates, instead of
hardcoding your objects’ URLs. For example, this template code is bad:

```html+django
<!-- BAD template code. Avoid! -->
<a href="/people/{{ object.id }}/">{{ object.name }}</a>
```

Den här mallkoden är mycket bättre:

```html+django
<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>
```

Logiken här är att om du ändrar URL-strukturen för dina objekt, även för något litet som att korrigera ett stavfel, vill du inte behöva spåra varje plats där URL kan skapas. Specificera den en gång, i `get_absolute_url()` och låt all din övriga kod anropa den enda platsen.

> **Note**
>
> Den sträng du returnerar från `get_absolute_url()` **måste** endast innehålla ASCII-tecken (krävs enligt URI-specifikationen, [**RFC 3986 Section 2**](https://datatracker.ietf.org/doc/html/rfc3986.html#section-2)) och vara URL-kodad, om nödvändigt.
>
> Kod och mallar som anropar `get_absolute_url()` bör kunna använda resultatet direkt utan någon ytterligare bearbetning. Du kanske vill använda funktionen `django.utils.encoding.iri_to_uri()` för att hjälpa till med detta om du använder strängar som innehåller tecken utanför ASCII-området.

## Extra instansmetoder

In addition to [`save()`](#django.db.models.Model.save), [`delete()`](#django.db.models.Model.delete), a model object
might have some of the following methods:

#### `Model.get_FOO_display()`

För varje fält som har [`choices`](/sv/6.1/ref/models/fields/#django.db.models.Field.choices) inställt, kommer objektet att ha en `get_FOO_display()` metod, där `FOO` är namnet på fältet. Denna metod returnerar det ”mänskligt läsbara” värdet för fältet.

Till exempel:

```
from django.db import models

class Person(models.Model):
    SHIRT_SIZES = {
        "S": "Small",
        "M": "Medium",
        "L": "Large",
    }
    name = models.CharField(max_length=60)
    shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)
```

```pycon
>>> p = Person(name="Fred Flintstone", shirt_size="L")
>>> p.save()
>>> p.shirt_size
'L'
>>> p.get_shirt_size_display()
'Large'
```

#### `Model.get_next_by_FOO(**kwargs)`

#### `Model.get_previous_by_FOO(**kwargs)`

För varje [`DateField`](/sv/6.1/ref/models/fields/#django.db.models.DateField) och [`DateTimeField`](/sv/6.1/ref/models/fields/#django.db.models.DateTimeField) som inte har [`null=True`](/sv/6.1/ref/models/fields/#django.db.models.Field.null), kommer objektet att ha `get_next_by_FOO()` och `get_previous_by_FOO()` metoder, där `FOO` är namnet på fältet. Detta returnerar nästa och föregående objekt med avseende på datumfältet och ger upphov till ett [`DoesNotExist`](/sv/6.1/ref/models/class/#django.db.models.Model.DoesNotExist)-undantag när det är lämpligt.

Båda dessa metoder kommer att utföra sina frågor med hjälp av standardhanteraren för modellen. Om du behöver emulera filtrering som används av en anpassad hanterare, eller vill utföra enstaka anpassad filtrering, accepterar båda metoderna också valfria nyckelordsargument, som bör vara i det format som beskrivs i [Field lookups](/sv/6.1/ref/models/querysets/#field-lookups).

Observera att om datumvärdena är identiska kommer dessa metoder att använda primärnyckeln som utslagsgivande. Detta garanterar att inga poster hoppas över eller dupliceras. Det innebär också att du inte kan använda dessa metoder på osparade objekt.

> **Åsidosättande av extra instansmetoder**
>
> I de flesta fall bör åsidosättande eller arv av `get_FOO_display()`, `get_next_by_FOO()` och `get_previous_by_FOO()` fungera som förväntat. Eftersom de läggs till av metaklassen är det dock inte praktiskt möjligt att ta hänsyn till alla möjliga arvsstrukturer. I mer komplexa fall bör du åsidosätta `Field.contribute_to_class()` för att ställa in de metoder du behöver.

## Övriga attribut

### `_stat`

#### `Model._state`

Attributet `_state` hänvisar till ett `ModelState`-objekt som spårar modellinstansens livscykel.

The `ModelState` object has three attributes: `adding`, a flag which is
`True` if the model has not been saved to the database yet, `db`, a
string referring to the database alias the instance was loaded from or
saved to, and `fetch_mode`, the [fetch mode](/sv/6.1/topics/db/fetch-modes/) to be used in subsequent field fetches.

Newly instantiated instances have `adding=True` and `db=None`,
since they are yet to be saved, and `fetch_mode=models.FETCH_ONE`.
Instances fetched from a `QuerySet` will have `adding=False`, `db`
set to the alias of the associated database, and `fetch_mode` copied
from the queryset’s fetch mode.

> **Changed in Django 6.1**
>
> The `fetch_mode` attribute was added.

### `_is_pk_set()`

#### `Model._is_pk_set()`

The `_is_pk_set()` method returns whether the model instance’s `pk` is
set. It abstracts the model’s primary key definition, ensuring consistent
behavior regardless of the specific `pk` configuration. A
`DatabaseDefault` on an unsaved instance is considered unset.

> **Changed in Django 6.1**
>
> In earlier versions, `True` was returned for `DatabaseDefault`
> values.