En lista över alla signaler som Django skickar. Alla inbyggda signaler skickas med hjälp av send()-metoden.
Modulen django.db.models.signals definierar en uppsättning signaler som skickas av modellsystemet.
pre_initLink to this heading#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:
\nDen modellklass som just fått en instans skapad.
\nargsEn lista med positionella argument som skickas till __init__().
kwargsEn ordlista med nyckelordsargument som skickas till __init__().
Till exempel: har tutorial den här raden:
\nq = Question(question_text="What's new?", pub_date=timezone.now())\nDe argument som skickas till en pre_init hanterare skulle vara:
Argument | \nVärde | \n
|---|---|
avsändare | \n
| \n
| \n
| \n
| \n
| \n
post_initLink to this heading#Som pre_init, men den här skickas när metoden __init__() är klar.
Argument som skickas med denna signal:
\nSom ovan: modellklassen som just har fått en instans skapad.
\ninstansDen faktiska instansen av den modell som just har skapats.
\n\npre_saveLink to this heading#Detta skickas i början av en modells save()-metod.
Argument som skickas med denna signal:
\nModellklassen.
\ninstansDen faktiska instans som sparas.
\nrawEn 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änderDet databasalias som används.
\nuppdatera_fältDen uppsättning fält som ska uppdateras enligt Model.save(), eller None om update_fields inte skickades till save().
post_saveLink to this heading#Som pre_save, men skickas i slutet av metoden save().
Argument som skickas med denna signal:
\nModellklassen.
\ninstansDen faktiska instans som sparas.
\nskapadEn boolean; True om en ny post skapades.
rawEn 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änderDet databasalias som används.
\nuppdatera_fältDen uppsättning fält som ska uppdateras enligt Model.save(), eller None om update_fields inte skickades till save().
pre_deleteLink to this heading#Skickas i början av en models delete()-metod och en querysets delete()-metod.
Argument som skickas med denna signal:
\nModellklassen.
\ninstansDen faktiska instans som raderas.
\nanvänderDet databasalias som används.
\nursprungDen instans av Model eller QuerySet från vilken borttagningen skedde, dvs. den instans vars metod delete() anropades.
post_deleteLink to this heading#Som pre_delete, men skickas i slutet av en models delete()-metod och en querysets delete()-metod.
Argument som skickas med denna signal:
\nModellklassen.
\ninstansDen faktiska instans som raderas.
\nObservera att objektet inte längre kommer att finnas i databasen, så var mycket försiktig med vad du gör med denna instans.
\nanvänderDet databasalias som används.
\nursprungDen instans av Model eller QuerySet från vilken borttagningen skedde, dvs. den instans vars metod delete() anropades.
m2m_changedLink to this heading#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:
\nDen 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 attributet through på many-to-many-fältet.
instansDen instans vars many-to-many-relation uppdateras. Detta kan vara en instans av sender, eller av den klass som ManyToManyField är relaterad till.
handlingEn sträng som anger vilken typ av uppdatering som görs av relationen. Detta kan vara något av följande:
\n"pre_add"Skickas innan ett eller flera objekt läggs till i relationen.
\n"post_add"Skickas efter att ett eller flera objekt har lagts till i relationen.
\n"pre_remove"Skickas innan ett eller flera objekt tas bort från relationen.
\n"post_remove"Skickas efter att ett eller flera objekt har tagits bort från relationen.
\n"pre_clear"Skickas innan relationen är avklarad.
\n"post_clear"Skickas efter att relationen är avklarad.
\nomvändAnger vilken sida av relationen som uppdateras (dvs. om det är den framåtriktade eller omvända relationen som ändras).
\nmodellKlassen för de objekt som läggs till i, tas bort från eller rensas från relationen.
\npk_setFör åtgärderna pre_add och post_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 ett IntegrityError i databasen.
För åtgärderna pre_remove och post_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å i pk_set, även om de inte har någon effekt på databasen.
För åtgärderna pre_clear och post_clear är detta None.
använderDet databasalias som används.
\nTill exempel:, om en Pizza kan ha flera Topping-objekt, modellerade så här:
class Topping(models.Model):\n # ...\n pass\n\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\nOm vi ansluter en hanterare så här:
\nfrom django.db.models.signals import m2m_changed\n\n\ndef toppings_changed(sender, **kwargs):\n # Do something\n pass\n\n\nm2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)\noch gjorde sedan något liknande:
\n>>> p = Pizza.objects.create(...)\n>>> t = Topping.objects.create(...)\n>>> p.toppings.add(t)\nde argument som skickas till en m2m_changed hanterare (toppings_changed i exemplet ovan) skulle vara:
Argument | \nVärde | \n
|---|---|
avsändare | \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
Och om vi då skulle göra något sådant här:
\n>>> t.pizza_set.remove(p)\nde argument som skickas till en m2m_changed hanterare skulle vara:
Argument | \nVärde | \n
|---|---|
avsändare | \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
klass_förbereddLink to this heading#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.
\nEftersom 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:
\nModellklassen som just var förberedd.
\nSignaler skickade av django-admin.
\npre_migrateLink to this heading#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:
\nEn AppConfig-instans för den applikation som ska migreras/synkroniseras.
app_configSamma som avsändare.
verbosityAnger 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.
interaktivOm interactive är True är det säkert att uppmana användaren att mata in saker på kommandoraden. Om interactive är False 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är interactive är True.
stdoutEtt strömliknande objekt som kan användas för att omdirigera verbose-utdata.
\nanvänderAliaset för den databas som ett kommando ska användas på.
\nplanDen 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).
appsEn 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 registret apps för att hämta de modeller som du vill utföra åtgärder på.
post_migreraLink to this heading#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:
\nEn AppConfig-instans för den applikation som just installerades.
app_configSamma som avsändare.
verbosityAnger 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.
interaktivOm interactive är True är det säkert att uppmana användaren att mata in saker på kommandoraden. Om interactive är False 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är interactive är True.
stdoutEtt strömliknande objekt som kan användas för att omdirigera verbose-utdata.
\nanvänderDet databasalias som används för synkronisering. Standard är databasen default.
planDen 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).
appsEn instans av Apps som innehåller projektets tillstånd efter migreringskörningen. Den bör användas i stället för det globala registret apps 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\nfrom django.db.models.signals import post_migrate\n\n\ndef my_callback(sender, **kwargs):\n # Your specific logic here\n pass\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n post_migrate.connect(my_callback, sender=self)\nSignaler som skickas av kärnramverket när en begäran behandlas.
\n\nbegäran_startadLink to this heading#Skickas när Django börjar bearbeta en HTTP-begäran.
\nArgument som skickas med denna signal:
\nHanteringsklassen - t.ex. django.core.handlers.wsgi.WsgiHandler - som hanterade begäran.
Den ordbok för ”miljö” som tillhandahålls för begäran.
\nSkickas när Django avslutar leveransen av ett HTTP-svar till klienten.
\nArgument som skickas med denna signal:
\nHanterarklassen, som ovan.
\nDenna signal skickas när Django stöter på ett undantag under behandlingen av en inkommande HTTP-begäran.
\nArgument som skickas med denna signal:
\nOanvänd (alltid None).
begäranObjektet HttpRequest.
Signaler skickas endast när kör tester.
\ninställning_ändradLink to this heading#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:
\nInställningshanteraren.
\ninställningNamnet på inställningen.
\nvärdeVärdet på inställningen efter ändringen. För inställningar som ursprungligen inte finns, i fasen ”teardown”, är value None.
enterEn boolean; True om inställningen tillämpas, False om den återställs.
template_renderedLink to this heading#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.
\nArgument som skickas med denna signal:
\n\nSignaler som skickas av databasomslaget när en databasanslutning initieras.
\nanslutning_skapadLink to this heading#Sent when the database wrapper makes the initial connection to the\ndatabase. This is particularly useful if you’d like to send any post\nconnection commands to the SQL backend.
\nArgument som skickas med denna signal:
\nDatabasens omslagsklass - t.ex. django.db.backends.postgresql.DatabaseWrapper eller django.db.backends.mysql.DatabaseWrapper, etc.
anslutningDen databasanslutning som öppnades. Detta kan användas i en konfiguration med flera databaser för att skilja på anslutningssignaler från olika databaser.
\nSignals sent by the tasks framework.
\ntask_enqueuedLink to this heading#Sent once a Task has been enqueued.
\nArgument som skickas med denna signal:
\nThe backend class which the Task was enqueued on to.
\ntask_resultThe enqueued TaskResult.
task_startedLink to this heading#Sent when a Task has started executing.
\nArgument som skickas med denna signal:
\nThe backend class which the Task was enqueued on to.
\ntask_resultThe started TaskResult.
task_finishedLink to this heading#Sent once a Task has finished executing, successfully or otherwise.
\nArgument som skickas med denna signal:
\nThe backend class which the Task was enqueued on to.
\ntask_resultThe finished TaskResult.