Signaler¶
En lista över alla signaler som Django skickar. Alla inbyggda signaler skickas med hjälp av send()
-metoden.
Se även
Se dokumentationen för signal dispatcher för information om hur du registrerar dig för och tar emot signaler.
Ramverket authentication sänder signaler när en användare är inloggad/utloggad.
Modellsignaler¶
Modulen django.db.models.signals
definierar en uppsättning signaler som skickas av modellsystemet.
Varning
Signaler kan göra din kod svårare att underhålla. Överväg att implementera en hjälpmetod på en custom manager, för att både uppdatera dina modeller och utföra ytterligare logik, eller annars overriding model methods innan du använder modellsignaler.
Varning
Många av dessa signaler skickas av olika modellmetoder som __init__()
eller save()
som du kan åsidosätta i din egen kod.
Om du åsidosätter dessa metoder i din modell måste du anropa den överordnade klassens metoder för att dessa signaler ska skickas.
Observera också att Django lagrar signalhanterare som svaga referenser som standard, så om din hanterare är en lokal funktion kan den bli skräpinsamlad. För att förhindra detta, skicka weak=False
när du anropar signalens connect()
.
Observera
Modellsignaler avsändare
-modeller kan refereras till när man ansluter en mottagare genom att ange dess fullständiga applikationsetikett. Till exempel: kan en Question
-modell som definieras i polls
-applikationen refereras som 'polls.Question'
. Denna typ av referens kan vara ganska praktisk när man hanterar cirkulära importberoenden och utbytbara modeller.
pre_init
¶
- django.db.models.signals.pre_init¶
När du instansierar en Django-modell skickas den här signalen i början av modellens metod __init__()
.
Argument som skickas med denna signal:
- avsändare
Den modellklass som just fått en instans skapad.
args
En lista med positionella argument som skickas till
__init__()
.kwargs
En ordlista med nyckelordsargument som skickas till
__init__()
.
Till exempel: har tutorial den här raden:
q = Question(question_text="What's new?", pub_date=timezone.now())
De argument som skickas till en pre_init
hanterare skulle vara:
Argument |
Värde |
---|---|
avsändare |
|
|
|
|
|
post_init
¶
- django.db.models.signals.post_init¶
Som pre_init, men den här skickas när metoden __init__()
är klar.
Argument som skickas med denna signal:
- avsändare
Som ovan: modellklassen som just har fått en instans skapad.
instans
Den faktiska instansen av den modell som just har skapats.
Observera
instance._state
ställs inte in innan signalenpost_init
skickas, så attributen_state
har alltid sina standardvärden. Till exempel: är_state.db
None
.
Varning
Av prestandaskäl bör du inte utföra frågor i mottagare av signalerna pre_init
eller post_init
eftersom de skulle utföras för varje instans som returneras under iterationen av queryset.
pre_save
¶
- django.db.models.signals.pre_save¶
Detta skickas i början av en modells save()
-metod.
Argument som skickas med denna signal:
- avsändare
Modellklassen.
instans
Den faktiska instans som sparas.
raw
En boolean;
True
om modellen sparas exakt som den presenteras (t.ex. vid laddning av en fixture). Man bör inte fråga/ändra andra poster i databasen eftersom databasen kanske inte är i ett konsekvent tillstånd ännu.använder
Det databasalias som används.
uppdatera_fält
Den uppsättning fält som ska uppdateras enligt
Model.save()
, ellerNone
omupdate_fields
inte skickades tillsave()
.
post_save
¶
- django.db.models.signals.post_save¶
Som pre_save
, men skickas i slutet av metoden save()
.
Argument som skickas med denna signal:
- avsändare
Modellklassen.
instans
Den faktiska instans som sparas.
skapad
En boolean;
True
om en ny post skapades.raw
En boolean;
True
om modellen sparas exakt som den presenteras (t.ex. vid laddning av en fixture). Man bör inte fråga/ändra andra poster i databasen eftersom databasen kanske inte är i ett konsekvent tillstånd ännu.använder
Det databasalias som används.
uppdatera_fält
Den uppsättning fält som ska uppdateras enligt
Model.save()
, ellerNone
omupdate_fields
inte skickades tillsave()
.
pre_delete
¶
- django.db.models.signals.pre_delete¶
Skickas i början av en models delete()
-metod och en querysets delete()
-metod.
Argument som skickas med denna signal:
- avsändare
Modellklassen.
instans
Den faktiska instans som raderas.
använder
Det databasalias som används.
ursprung
Den instans av
Model
ellerQuerySet
från vilken borttagningen skedde, dvs. den instans vars metoddelete()
anropades.
post_delete
¶
- django.db.models.signals.post_delete¶
Som pre_delete
, men skickas i slutet av en models delete()
-metod och en querysets delete()
-metod.
Argument som skickas med denna signal:
- avsändare
Modellklassen.
instans
Den faktiska instans som raderas.
Observera att objektet inte längre kommer att finnas i databasen, så var mycket försiktig med vad du gör med denna instans.
använder
Det databasalias som används.
ursprung
Den instans av
Model
ellerQuerySet
från vilken borttagningen skedde, dvs. den instans vars metoddelete()
anropades.
m2m_changed
¶
- django.db.models.signals.m2m_changed¶
Skickas när en ManyToManyField
ändras på en modellinstans. Strängt taget är detta inte en modellsignal eftersom den skickas av ManyToManyField
, men eftersom den kompletterar pre_save
/post_save
och pre_delete
/post_delete
när det gäller att spåra ändringar i modeller, inkluderas den här.
Argument som skickas med denna signal:
- avsändare
Den mellanliggande modellklassen som beskriver
ManyToManyField
. Denna klass skapas automatiskt när ett many-to-many-fält definieras; du kan komma åt den med hjälp av attributetthrough
på many-to-many-fältet.instans
Den instans vars many-to-many-relation uppdateras. Detta kan vara en instans av
sender
, eller av den klass somManyToManyField
är relaterad till.handling
En sträng som anger vilken typ av uppdatering som görs av relationen. Detta kan vara något av följande:
"pre_add"`
Skickas innan ett eller flera objekt läggs till i relationen.
"post_add"`
Skickas efter att ett eller flera objekt har lagts till i relationen.
"pre_remove"`
Skickas innan ett eller flera objekt tas bort från relationen.
"post_remove"`
Skickas efter att ett eller flera objekt har tagits bort från relationen.
"pre_clear"`
Skickas innan relationen är avklarad.
"post_clear"`
Skickas efter att relationen är avklarad.
omvänd
Anger vilken sida av relationen som uppdateras (dvs. om det är den framåtriktade eller omvända relationen som ändras).
modell
Klassen för de objekt som läggs till i, tas bort från eller rensas från relationen.
pk_set
För åtgärderna
pre_add
ochpost_add
är detta en uppsättning primärnyckelvärden som kommer att läggas till, eller har lagts till, i relationen. Detta kan vara en delmängd av de värden som lämnats in för att läggas till, eftersom inmatningar måste filtrera befintliga värden för att undvika ettIntegrityError
i databasen.För åtgärderna
pre_remove
ochpost_remove
är detta en uppsättning primärnyckelvärden som skickades in för att tas bort från relationen. Detta är inte beroende av om värdena faktiskt kommer att tas bort eller har tagits bort. I synnerhet kan icke-existerande värden skickas in och visas då ipk_set
, även om de inte har någon effekt på databasen.För åtgärderna
pre_clear
ochpost_clear
är dettaNone
.använder
Det databasalias som används.
Till exempel:, om en Pizza
kan ha flera Topping
-objekt, modellerade så här:
class Topping(models.Model):
# ...
pass
class Pizza(models.Model):
# ...
toppings = models.ManyToManyField(Topping)
Om vi ansluter en hanterare så här:
from django.db.models.signals import m2m_changed
def toppings_changed(sender, **kwargs):
# Do something
pass
m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)
och gjorde sedan något liknande:
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
de argument som skickas till en m2m_changed
hanterare (toppings_changed
i exemplet ovan) skulle vara:
Argument |
Värde |
---|---|
avsändare |
|
|
|
|
|
|
|
|
|
|
|
|
|
Och om vi då skulle göra något sådant här:
>>> t.pizza_set.remove(p)
de argument som skickas till en m2m_changed
hanterare skulle vara:
Argument |
Värde |
---|---|
avsändare |
|
|
|
|
|
|
|
|
|
|
|
|
|
klass_förberedd
¶
- django.db.models.signals.class_prepared¶
Skickas när en modellklass har ”förberetts”, det vill säga när en modell har definierats och registrerats i Djangos modellsystem. Django använder denna signal internt; den används vanligtvis inte i tredjepartsapplikationer.
Eftersom den här signalen skickas under appregisterpopulationsprocessen och AppConfig.ready()
körs efter att appregistret är helt populerat, kan mottagare inte anslutas i den metoden. En möjlighet är att ansluta dem till AppConfig.__init__()
istället, och se till att inte importera modeller eller utlösa anrop till appregistret.
Argument som skickas med denna signal:
- avsändare
Modellklassen som just var förberedd.
Ledningens signaler¶
Signaler skickade av django-admin.
pre_migrate
¶
- django.db.models.signals.pre_migrate¶
Skickas av kommandot migrate
innan det börjar installera ett program. Det sänds inte ut för program som saknar en models
-modul.
Argument som skickas med denna signal:
- avsändare
En
AppConfig
-instans för den applikation som ska migreras/synkroniseras.app_config
Samma som
avsändare
.verbosity
Anger hur mycket information
manage.py
skriver ut på skärmen. Se flaggan--verbosity
för mer information.Funktioner som lyssnar efter
pre_migrate
bör justera vad de matar ut på skärmen baserat på värdet av detta argument.interaktiv
Om
interactive
ärTrue
är det säkert att uppmana användaren att mata in saker på kommandoraden. Ominteractive
ärFalse
ska funktioner som lyssnar på denna signal inte försöka uppmana till något.Till exempel: uppmanar
django.contrib.auth
-appen bara till att skapa en superanvändare närinteractive
ärTrue
.stdout
Ett strömliknande objekt som kan användas för att omdirigera verbose-utdata.
använder
Aliaset för den databas som ett kommando ska användas på.
plan
Den migreringsplan som kommer att användas för migreringskörningen. Planen är inte ett publikt API, men detta möjliggör de sällsynta fall då det är nödvändigt att känna till planen. En plan är en lista med 2-tuples där det första objektet är en instans av en migreringsklass och det andra objektet visar om migreringen rullades tillbaka (
True
) eller tillämpades (False
).apps
En instans av
Apps
som innehåller projektets tillstånd före migreringskörningen. Den bör användas i stället för det globala registretapps
för att hämta de modeller som du vill utföra åtgärder på.
post_migrera
¶
- django.db.models.signals.post_migrate¶
Skickas i slutet av kommandona migrate
(även om inga migreringar körs) och flush
. Det sänds inte ut för program som saknar en models
-modul.
Den som hanterar den här signalen får inte ändra databasscheman eftersom det kan leda till att kommandot flush
misslyckas om det körs under kommandot migrate
.
Argument som skickas med denna signal:
- avsändare
En
AppConfig
-instans för den applikation som just installerades.app_config
Samma som
avsändare
.verbosity
Anger hur mycket information
manage.py
skriver ut på skärmen. Se flaggan--verbosity
för mer information.Funktioner som lyssnar på
post_migrate
bör justera vad de matar ut på skärmen baserat på värdet av detta argument.interaktiv
Om
interactive
ärTrue
är det säkert att uppmana användaren att mata in saker på kommandoraden. Ominteractive
ärFalse
ska funktioner som lyssnar på denna signal inte försöka uppmana till något.Till exempel: uppmanar
django.contrib.auth
-appen bara till att skapa en superanvändare närinteractive
ärTrue
.stdout
Ett strömliknande objekt som kan användas för att omdirigera verbose-utdata.
använder
Det databasalias som används för synkronisering. Standard är databasen
default
.plan
Den migreringsplan som användes för migreringskörningen. Planen är inte ett offentligt API, men detta möjliggör de sällsynta fall då det är nödvändigt att känna till planen. En plan är en lista med 2-tuples där det första objektet är en instans av en migreringsklass och det andra objektet visar om migreringen rullades tillbaka (
True
) eller tillämpades (False
).apps
En instans av
Apps
som innehåller projektets tillstånd efter migreringskörningen. Den bör användas i stället för det globala registretapps
för att hämta de modeller som du vill utföra åtgärder på.
Du kan till exempel registrera en återuppringning i en AppConfig
så här:
from django.apps import AppConfig
from django.db.models.signals import post_migrate
def my_callback(sender, **kwargs):
# Your specific logic here
pass
class MyAppConfig(AppConfig):
...
def ready(self):
post_migrate.connect(my_callback, sender=self)
Observera
Om du anger en AppConfig
-instans som avsändarargument, se till att signalen är registrerad i ready()
. AppConfig
återskapas för tester som körs med en modifierad uppsättning av INSTALLED_APPS
(t.ex. när inställningar åsidosätts) och sådana signaler bör anslutas för varje ny AppConfig
-instans.
Signaler för begäran/svar¶
Signaler som skickas av kärnramverket när en begäran behandlas.
Varning
Signaler kan göra din kod svårare att underhålla. Överväg använda ett mellanprogram innan du använder request/response-signaler.
begäran_startad
¶
- django.core.signals.request_started¶
Skickas när Django börjar bearbeta en HTTP-begäran.
Argument som skickas med denna signal:
- avsändare
Hanteringsklassen - t.ex.
django.core.handlers.wsgi.WsgiHandler
- som hanterade begäran.- omgivning
Den ordbok för ”miljö” som tillhandahålls för begäran.
”Begäran_avslutad¶
- django.core.signals.request_finished¶
Skickas när Django avslutar leveransen av ett HTTP-svar till klienten.
Argument som skickas med denna signal:
- avsändare
Hanterarklassen, som ovan.
har fått undantag från begäran¶
- django.core.signals.got_request_exception¶
Denna signal skickas när Django stöter på ett undantag under behandlingen av en inkommande HTTP-begäran.
Argument som skickas med denna signal:
- avsändare
Oanvänd (alltid
None
).begäran
Objektet
HttpRequest
.
Test av signaler¶
Signaler skickas endast när kör tester.
inställning_ändrad
¶
- django.test.signals.setting_changed¶
Denna signal skickas när värdet på en inställning ändras via kontexthanteraren django.test.TestCase.settings()
eller django.test.override_settings()
dekorator/kontexthanteraren.
Det skickas faktiskt två gånger: när det nya värdet tillämpas (”setup”) och när det ursprungliga värdet återställs (”teardown”). Använd argumentet enter
för att skilja mellan de två.
Du kan också importera den här signalen från django.core.signals
för att undvika import från django.test
i situationer som inte är test.
Argument som skickas med denna signal:
- avsändare
Inställningshanteraren.
inställning
Namnet på inställningen.
värde
Värdet på inställningen efter ändringen. För inställningar som ursprungligen inte finns, i fasen ”teardown”, är
value
None
.enter
En boolean;
True
om inställningen tillämpas,False
om den återställs.
template_rendered
¶
- django.test.signals.template_rendered¶
Skickas när testsystemet renderar en mall. Denna signal sänds inte ut under normal drift av en Django-server - den är endast tillgänglig under testning.
Argument som skickas med denna signal:
- avsändare
Objektet
Template
som renderades.mall
Samma som avsändaren
kontext
Den :klass:`~django.template.Context` med vilken mallen renderades.
Databas-omslag¶
Signaler som skickas av databasomslaget när en databasanslutning initieras.
anslutning_skapad
¶
- django.db.backends.signals.connection_created¶
Skickas när databasomslaget gör den första anslutningen till databasen. Detta är särskilt användbart om du vill skicka kommandon efter anslutningen till SQL-backend.
Argument som skickas med denna signal:
- avsändare
Databasens omslagsklass - t.ex.
django.db.backends.postgresql.DatabaseWrapper
ellerdjango.db.backends.mysql.DatabaseWrapper
, etc.anslutning
Den databasanslutning som öppnades. Detta kan användas i en konfiguration med flera databaser för att skilja på anslutningssignaler från olika databaser.