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:
\nDen ”andra sidan” av en ForeignKey-relation. Det vill säga:
from django.db import models\n\n\nclass Blog(models.Model):\n # ...\n pass\n\n\nclass Entry(models.Model):\n blog = models.ForeignKey(Blog, on_delete=models.CASCADE, null=True)\nI 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):\n # ...\n pass\n\n\nclass Pizza(models.Model):\n toppings = models.ManyToManyField(Topping)\nI det här exemplet kommer metoderna nedan att vara tillgängliga både på topping.pizza_set och på pizza.toppings.
Asynkron version: aadd
Lägger till de angivna modellobjekten i den relaterade objektuppsättningen.
\nExempel:
\n>>> b = Blog.objects.get(id=1)\n>>> e = Entry.objects.get(id=234)\n>>> b.entry_set.add(e) # Associates Entry e with Blog b.\nI 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.
Asynkron version: acreate
Skapar ett nytt objekt, sparar det och lägger till det i den relaterade objektuppsättningen. Returnerar det nyskapade objektet:
\n>>> b = Blog.objects.get(id=1)\n>>> e = b.entry_set.create(\n... headline="Hello", body_text="Hi", pub_date=datetime.date(2005, 1, 1)\n... )\n\n# No need to call e.save() at this point -- it's already been saved.\nDetta är likvärdigt med (men enklare än):
\n>>> b = Blog.objects.get(id=1)\n>>> e = Entry(blog=b, headline="Hello", body_text="Hi", pub_date=datetime.date(2005, 1, 1))\n>>> e.save(force_insert=True)\nObservera 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.
Asynkron version: aremove
Tar bort de angivna modellobjekten från den relaterade objektuppsättningen:
\n>>> b = Blog.objects.get(id=1)\n>>> e = Entry.objects.get(id=234)\n>>> b.entry_set.remove(e) # Disassociates Entry e from Blog b.\nI likhet med add() anropas e.save() i exemplet ovan för att utföra uppdateringen. Om du använder remove() med en många-till-många-relation raderas dock relationerna med QuerySet.delete() vilket innebär att inga save()-metoder anropas; lyssna på m2m_changed-signalen om du vill köra anpassad kod när en relation raderas.
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.
Asynkron version: aclear
Tar bort alla objekt från den relaterade objektuppsättningen:
\n>>> b = Blog.objects.get(id=1)\n>>> b.entry_set.clear()\nObservera att detta inte raderar de relaterade objekten - de kopplas bara isär.
\nPrecis 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.
Asynkron version: aset
Byt ut uppsättningen av relaterade objekt:
\n>>> new_list = [obj1, obj2, obj3]\n>>> e.related_set.set(new_list)\nDenna 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.