# Django 6.0.5 documentation

# Relaterade objekt referens

class RelatedManager

  En ”relaterad manager” är en manager som används i ett relaterat sammanhang en-till-många eller många-till-många. Detta sker i två fall:

  - Den ”andra sidan” av en `ForeignKey`-relation. Det vill säga:

        from django.db import models

        class Blog(models.Model):
            # ...
            pass

        class Entry(models.Model):
            blog = models.ForeignKey(Blog, on_delete=models.CASCADE, null=True)

    I exemplet ovan kommer metoderna nedan att vara tillgängliga för förvaltaren `blog.entry_set`.

  - Båda sidor av en `ManyToManyField` relation

        class Topping(models.Model):
            # ...
            pass

        class Pizza(models.Model):
            toppings = models.ManyToManyField(Topping)

    I det här exemplet kommer metoderna nedan att vara tillgängliga både på `topping.pizza_set` och på `pizza.toppings`.

  add(*objs, bulk=True, through_defaults=None)
  aadd(*objs, bulk=True, through_defaults=None)

    Asynkron version: `aadd`

    Lägger till de angivna modellobjekten i den relaterade objektuppsättningen.

    Exempel:

        >>> b = Blog.objects.get(id=1)
        >>> e = Entry.objects.get(id=234)
        >>> b.entry_set.add(e)  # Associates Entry e with Blog b.

    I exemplet ovan, när det gäller en `ForeignKey`-relation, används `QuerySet.update()` för att utföra uppdateringen. Detta kräver att objekten redan är sparade.

    Du kan använda argumentet `bulk=False` för att istället låta den relaterade hanteraren utföra uppdateringen genom att anropa `e.save()`.

    Om du använder `add()` med en many-to-many-relation kommer dock inga `save()`-metoder att anropas (argumentet `bulk` finns inte), utan relationerna skapas med `QuerySet.bulk_create()`. Om du behöver köra någon anpassad logik när en relation skapas, lyssna på `m2m_changed`-signalen, som kommer att utlösa `pre_add` och `post_add`-åtgärder.

    Om du använder `add()` på en relation som redan finns kommer relationen inte att dupliceras, men den kommer fortfarande att utlösa signaler.

    För många-till-många-relationer accepterar `add()` antingen modellinstanser eller fältvärden, normalt primärnycklar, som argumentet `*objs`.

    Använd argumentet `through_defaults` för att ange värden för den nya intermediate model-instansen (instanserna), om det behövs. Du kan använda callables som värden i ordlistan `through_defaults` och de kommer att utvärderas en gång innan någon eller några mellanliggande instanser skapas.

  create(through_defaults=None, **kwargs)
  acreate(through_defaults=None, **kwargs)

    Asynkron version: `acreate`

    Skapar ett nytt objekt, sparar det och lägger till det i den relaterade objektuppsättningen. Returnerar det nyskapade objektet:

        >>> b = Blog.objects.get(id=1)
        >>> e = b.entry_set.create(
        ...     headline="Hello", body_text="Hi", pub_date=datetime.date(2005, 1, 1)
        ... )

        # No need to call e.save() at this point -- it's already been saved.

    Detta är likvärdigt med (men enklare än):

        >>> b = Blog.objects.get(id=1)
        >>> e = Entry(blog=b, headline="Hello", body_text="Hi", pub_date=datetime.date(2005, 1, 1))
        >>> e.save(force_insert=True)

    Observera att det inte finns något behov av att ange nyckelordsargumentet för den modell som definierar relationen. I exemplet ovan skickar vi inte parametern `blog` till `create()`. Django räknar ut att det nya `Entry`-objektets `blog`-fält ska sättas till `b`.

    Använd argumentet `through_defaults` för att ange värden för den nya instansen intermediate model, om det behövs. Du kan använda callables som värden i ordlistan `through_defaults`.

  remove(*objs, bulk=True)
  aremove(*objs, bulk=True)

    Asynkron version: `aremove`

    Tar bort de angivna modellobjekten från den relaterade objektuppsättningen:

        >>> b = Blog.objects.get(id=1)
        >>> e = Entry.objects.get(id=234)
        >>> b.entry_set.remove(e)  # Disassociates Entry e from Blog b.

    Similar to `add()`, `e.save()` is called in the example above to perform the update. Using `remove()` with a many-to-many relationship, however, will delete the relationships using `QuerySet.delete()` which means no model `save()` methods are called; listen to the `m2m_changed` signal if you wish to execute custom code when a relationship is deleted.

    För många-till-många-relationer accepterar `remove()` antingen modellinstanser eller fältvärden, normalt primärnycklar, som argumentet `*objs`.

    För `ForeignKey`-objekt finns denna metod endast om `null=True`. Om det relaterade fältet inte kan sättas till `None` (`NULL`), kan ett objekt inte tas bort från en relation utan att läggas till i en annan. I exemplet ovan är att ta bort `e` från `b.entry_set()` likvärdigt med att göra `e.blog = None`, och eftersom `blog` `ForeignKey` inte har `null=True` är detta ogiltigt.

    För `ForeignKey`-objekt accepterar denna metod ett `bulk`-argument för att styra hur operationen ska utföras. Om `True` (standard) används `QuerySet.update()`. Om `bulk=False` anropas istället metoden `save()` för varje enskild modellinstans. Detta utlöser signalerna `pre_save` och `post_save` och sker på bekostnad av prestanda.

    För många-till-många-relationer finns inte nyckelordsargumentet `bulk`.

  clear(bulk=True)
  aclear(bulk=True)

    Asynkron version: `aclear`

    Tar bort alla objekt från den relaterade objektuppsättningen:

        >>> b = Blog.objects.get(id=1)
        >>> b.entry_set.clear()

    Observera att detta inte raderar de relaterade objekten - de kopplas bara isär.

    Precis som `remove()` är `clear()` endast tillgänglig på `ForeignKey`` där `null=True` och den accepterar också nyckelordsargumentet `bulk`.

    För många-till-många-relationer finns inte nyckelordsargumentet `bulk`.

  set(objs, bulk=True, clear=False, through_defaults=None)
  aset(objs, bulk=True, clear=False, through_defaults=None)

    Asynkron version: `aset`

    Byt ut uppsättningen av relaterade objekt:

        >>> new_list = [obj1, obj2, obj3]
        >>> e.related_set.set(new_list)

    Denna metod accepterar ett `clear`-argument för att styra hur operationen ska utföras. Om `False` (standard), tas de element som saknas i den nya uppsättningen bort med `remove()` och endast de nya läggs till. Om `clear=True` anropas istället metoden `clear()` och hela uppsättningen läggs till på en gång.

    För `ForeignKey`-objekt skickas `bulk`-argumentet vidare till `add()` och `remove()`.

    För många-till-många-relationer finns inte nyckelordsargumentet `bulk`.

    Observera att eftersom `set()` är en sammansatt operation kan den vara föremål för tävlingsvillkor. Exempelvis kan nya objekt läggas till i databasen mellan anropet till `clear()` och anropet till `add()`.

    För många-till-många-relationer accepterar `set()` en lista med antingen modellinstanser eller fältvärden, normalt primärnycklar, som `objs`-argument.

    Använd argumentet `through_defaults` för att ange värden för den nya intermediate model-instansen (instanserna), om det behövs. Du kan använda callables som värden i ordlistan `through_defaults` och de kommer att utvärderas en gång innan någon eller några mellanliggande instanser skapas.

  Observera

  Observera att `add()`, `aadd()`, `create()`, `acreate()`, `remove()`, `aremove()`, `clear()`, `aclear()`, `set()` och `aset()` alla tillämpar databasändringar omedelbart för alla typer av relaterade fält. Med andra ord behöver du inte anropa `save()`/asave()` i någon av ändarna av relationen.

  Om du använder `prefetch_related()`, rensar metoderna `add()`, `aadd()`, `remove()`, `aremove()`, `clear()`, `aclear()`, `set()` och `aset()` den prefetchade cachen.