Una lista de todos los señales que Django envía. Todas las señales integradas se envían utilizando el método send().
Ver también
Consulte la documentación sobre el dispatcher de señales para obtener información sobre cómo registrar y recibir señales.
El marco de autenticación envía señales cuando un usuario se loguea / desloguea.
El módulo django.db.models.signals define un conjunto de señales enviadas por el sistema del modelo.
Advertencia
Las señales pueden hacer que tu código sea más difícil de mantener. Considera implementar un método auxiliar en un administrador personalizado, para actualizar tus modelos y realizar lógica adicional, o bien sobreescribir métodos del modelo antes de utilizar señales de modelos.
Advertencia
Muchas de estas señales son enviadas por diversos métodos de modelo como __init__() o save() que puedes sobrescribir en tu propio código.
Si sobreescribes estos métodos en tu modelo, debes llamar a los métodos de la clase padre para que estas señales sean enviadas.
También ten en cuenta que Django almacena manejadores de señales como referencias débiles por defecto, por lo que si tu manejador es una función local, puede ser recogido por el recolector. Para evitar esto, pasa weak=False cuando llames a la conexión del connect().
Nota
Los modelos de señales sender pueden referenciarse de manera perezosa al conectar un receptor especificando su etiqueta de aplicación completa. Por ejemplo, un modelo Question definido en la aplicación polls podría ser referenciado como 'polls.Question'. Este tipo de referencia puede resultar muy útil cuando se tratan dependencias de importación circulares y modelos intercambiables.
pre_init¶Cuando instancias un modelo Django, esta señal es enviada al comienzo del método __init__() del modelo.
Argumentos enviados con este señal:
La clase del modelo que acaba de tener una instancia creada.
argsUna lista de argumentos posicionales pasados a __init__().
kwargsUn diccionario de argumentos clave-valor pasados a __init__().
Por ejemplo, el tutorial tiene esta línea:
q = Question(question_text="What's new?", pub_date=timezone.now())
Los argumentos enviados a un pre_init handler serían:
Argumento |
Valor |
|---|---|
sender |
|
|
|
|
|
post_init¶De la misma manera que pre_init, pero este se envía cuando el método __init__() termina.
Argumentos enviados con este señal:
Los textos traducidos son:
instanceLa instancia real del modelo que se ha creado recientemente.
Nota
instance._state no está configurado antes de enviar el señal post_init, por lo que los atributos _state siempre tienen sus valores predeterminados. Por ejemplo, _state.db es None.
Advertencia
Por razones de rendimiento, no debes realizar consultas en receptores de las señales pre_init o post_init porque se ejecutarían para cada instancia devuelta durante la iteración del conjunto de resultados.
pre_save¶Se envía al principio del método save() del modelo.
Argumentos enviados con este señal:
El modelo clase.
instanceLa instancia real que se está guardando.
rawUn booleano; True si el modelo se guarda exactamente como se presenta (es decir, cuando se carga un fixture). No debes consultar/Modificar otros registros en la base de datos ya que la base de datos puede no estar en un estado consistente todavía.
usandoEl alias de la base de datos que se está utilizando.
update_fieldsEl conjunto de campos para actualizar tal como se pasa a Model.save(), o None si update_fields no se pasó a save().
post_save¶Como pre_save, pero enviado al final del método save().
Argumentos enviados con este señal:
El modelo clase.
instanceLa instancia real que se está guardando.
createdUn booleano; True si se creó un nuevo registro.
rawUn booleano; True si el modelo se guarda exactamente como se presenta (es decir, cuando se carga un fixture). No debes consultar/Modificar otros registros en la base de datos ya que la base de datos puede no estar en un estado consistente todavía.
usandoEl alias de la base de datos que se está utilizando.
update_fieldsEl conjunto de campos para actualizar tal como se pasa a Model.save(), o None si update_fields no se pasó a save().
pre_delete¶Se envía al comienzo del método de eliminación delete() de un modelo y el método delete() de una consulta.
Argumentos enviados con este señal:
El modelo clase.
instanceLa instancia real que se está borrando.
usandoEl alias de la base de datos que se está utilizando.
origenThe Model or QuerySet instance from which the deletion originated, that es decir, el instante cuyo método delete() fue invocado.
post_delete¶Como pre_delete, pero enviado al final del método de eliminación de un modelo y un conjunto de consultas delete() y delete().
Argumentos enviados con este señal:
El modelo clase.
instanceLa instancia real que se está borrando.
Nota que el objeto ya no estará en la base de datos, por lo que ten cuidado con lo que hagas con esta instancia.
usandoEl alias de la base de datos que se está utilizando.
origenThe Model or QuerySet instance from which the deletion originated, that es decir, el instante cuyo método delete() fue invocado.
m2m_changed¶Se envía cuando se cambia un ManyToManyField en una instancia de modelo. En rigor, esto no es un señal de modelo ya que se envía por la clase ManyToManyField, pero como complementa las señales pre_save/post_save y pre_delete/post_delete cuando se trata de rastrear cambios en modelos, se incluye aquí.
Argumentos enviados con este señal:
La clase que describe el modelo intermedio de la relación ManyToManyField. Esta clase se crea automáticamente cuando se define un campo many-to-many; puedes acceder a ella utilizando el atributo through del campo many-to-many.
instanceLa instancia cuya relación many-to-many está actualizada. Esto puede ser una instancia de la sender, o de la clase al que está relacionado el ManyToManyField.
actionUna cadena que indica el tipo de actualización que se hace en la relación. Puede ser uno de los siguientes:
Se envía antes de que uno o más objetos se agreguen a la relación.
Se envía después de que uno o más objetos se agregan a la relación.
Se envía antes de que uno o más objetos sean eliminados de la relación.
Se envía después de que uno o más objetos son eliminados de la relación.
"antes_de_limpiar"Se envía antes de que la relación se limpie.
"post_clear"Sentido después de que la relación se ha limpiado.
inversoIndica qué lado de la relación está actualizado (es decir, si es la relación hacia adelante o hacia atrás que está siendo modificada).
modelLa clase de los objetos que se agregan a, eliminan de o limpian de la relación.
pk_setPara las acciones pre_add y post_add, este es un conjunto de valores de clave primaria que se agregarán o han sido agregados a la relación. Esto puede ser un subconjunto de los valores presentados para agregar, ya que los insertos deben filtrar los valores existentes para evitar un error de integridad del servidor.
Para las acciones pre_remove y post_remove, este es un conjunto de valores de clave primaria que se han presentado para eliminar de la relación. Esto no depende de si los valores realmente se eliminarán o no. En particular, los valores inexistentes pueden ser presentados y aparecer en pk_set, aunque no tengan efecto en el servidor.
Para las acciones pre_clear y post_clear, este es None.
usandoEl alias de la base de datos que se está utilizando.
Por ejemplo, si una Pizza puede tener múltiples objetos Topping, modelados de esta manera:
class Topping(models.Model):
# ...
pass
class Pizza(models.Model):
# ...
toppings = models.ManyToManyField(Topping)
Si conectamos un manejador de esta forma:
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)
y luego hizo algo así:
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
los argumentos enviados a un manipulador de m2m_changed (m2m_changed) (por ejemplo, toppings_changed en el ejemplo anterior) serían:
Argumento |
Valor |
|---|---|
sender |
Pizza.toppings.through (la clase intermedia de m2m) |
|
|
|
|
|
|
|
Topping (la clase de los objetos agregados a la |
|
|
|
«predeterminado» (ya que el router predeterminado envía escrituras aquí) |
Y si luego hicéramos algo así:
>>> t.pizza_set.remove(p)
Los argumentos enviados a un manipulador de señal m2m_changed serían:
Argumento |
Valor |
|---|---|
sender |
Pizza.toppings.through (la clase intermedia de m2m) |
|
|
|
|
|
|
|
|
|
|
|
«predeterminado» (ya que el router predeterminado envía escrituras aquí) |
class_prepared¶Se envía esta señal cada vez que una clase de modelo ha sido «preparada» – es decir, una vez que un modelo ha sido definido y registrado con el sistema de modelos de Django. Django utiliza internamente esta señal; no se utiliza generalmente en aplicaciones de terceros.
Dado que esta señal se envía durante el proceso de población del registro de la aplicación, y AppConfig.ready() se ejecuta después de que el registro de la aplicación esté completamente poblado, no es posible conectar receptores en ese método. Una posibilidad es conectarlos en AppConfig.__init__() en lugar de eso, teniendo cuidado de no importar modelos ni desencadenar llamadas al registro de la aplicación.
Los argumentos que se envían con esta señal:
La clase del modelo que se acaba de preparar.
Señales enviadas por django-admin.
Enviado por la orden :djadmin:`migrate antes de que comience a instalar una aplicación. No se emite para aplicaciones que carecen de un módulo models.
Argumentos enviados con este señal:
Una instancia de la clase ~django.apps.AppConfig para la aplicación que se va a migrar/sincronizar.
Lo mismo que sender.
Indica cuánta información está imprimiendo manage.py en la pantalla. Consulte la bandera –verbosity para obtener más detalles.
Las traducciones son:
interactiveSi interactive es True, es seguro solicitar al usuario que ingrese cosas en la línea de comandos. Si interactive es False, las funciones que escuchan por este señal no deben intentar solicitar nada.
Por ejemplo, la aplicación django.contrib.auth solo solicita crear un superusuario cuando interactive es True.
stdoutUn objeto similar a un flujo donde se debe redirigir el output detallado.
usandoEl alias de la base de datos en la que se operará una orden.
planEl plan de migración que se va a utilizar para la ejecución de la migración. Si bien el plan no es API pública, esto permite los raros casos en los que es necesario saber el plan. Un plan es una lista de 2-tuplas con el primer elemento siendo la instancia de una clase de migración y el segundo elemento mostrando si la migración se deshizo (True) o se aplicó (False).
appsUna instancia de Apps que contiene el estado del proyecto antes de la ejecución de la migración. Debe usarse en lugar del registro global apps para recuperar los modelos sobre los cuales se desean realizar operaciones.
post_migrate¶Se envía al final de los comandos migrate (incluso si no se ejecutan migraciones) y flush. No se emite para aplicaciones que carecen de un módulo models.
Los manejadores de este señal deben evitar realizar alteraciones del esquema de la base de datos, ya que hacerlo puede causar que el comando flush falle si se ejecuta durante el comando migrate.
Argumentos enviados con este señal:
Una instancia de AppConfig para la aplicación que fue instalada recientemente.
Lo mismo que sender.
Indica cuánta información está imprimiendo manage.py en la pantalla. Consulte la bandera –verbosity para obtener más detalles.
Las funciones que escuchan por post_migrate deben ajustar qué salen a la pantalla en función del valor de este argumento.
interactiveSi interactive es True, es seguro solicitar al usuario que ingrese cosas en la línea de comandos. Si interactive es False, las funciones que escuchan por este señal no deben intentar solicitar nada.
Por ejemplo, la aplicación django.contrib.auth solo solicita crear un superusuario cuando interactive es True.
stdoutUn objeto similar a un flujo donde se debe redirigir el output detallado.
usandoEl alias de base de datos utilizado para la sincronización. Por defecto es el default.
planLa planificación de migración que se utilizó para la ejecución de la migración. Si bien la planificación no es API pública, esto permite los raros casos en los que es necesario saber la planificación. Una planificación es una lista de 2-tuplas con el primer elemento siendo una instancia de una clase de migración y el segundo elemento mostrando si la migración se deshizo (True) o se aplicó (False).
appsUna instancia de Apps que contiene el estado del proyecto después de la ejecución de la migración. Debe usarse en lugar del registro global apps para recuperar los modelos sobre los cuales se desean realizar operaciones.
Por ejemplo, podrías registrar un callback en una AppConfig como este:
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)
Nota
Si proporcionas una instancia de AppConfig como argumento del emisor, asegúrate de que el señal esté registrada en ready(). Las configuraciones AppConfig se recrean para las pruebas que ejecutan un conjunto modificado de INSTALLED_APPS (como cuando se sobrescriben los ajustes) y dichas señales deben estar conectadas para cada nueva instancia de AppConfig.
Señales enviadas por el núcleo del framework cuando se procesa una solicitud HTTP.
Advertencia
Considera usar un middleware antes de utilizar señales de solicitud/respuesta. Las señales pueden hacer que tu código sea más difícil de mantener. Consulta el uso de un middleware.
request_started¶Se envía cuando Django comienza a procesar una solicitud HTTP.
Argumentos enviados con este señal:
La clase del manejador – por ejemplo, django.core.handlers.wsgi.WsgiHandler – que manejo la solicitud.
environEl diccionario environ proporcionado a la solicitud.
request_finished¶Sent when Django finishes delivering an HTTP response to the cliente.
Argumentos enviados con este señal:
La clase del manejador, tal como se describe arriba.
got_request_exception¶Este señal se envía siempre que Django encuentra una excepción mientras procesa una solicitud HTTP entrante.
Argumentos enviados con este señal:
No utilizado (siempre None).
El objeto HttpRequest.
Las señales solo se envían cuando se están ejecutando pruebas.
setting_changed¶Este señal se envía cuando el valor de una configuración cambia a través del contexto django.test.TestCase.settings() o del decorador/contexto django.test.override_settings().
Se envía realmente dos veces: cuando se aplica el nuevo valor («setup») y cuando se restaura el valor original («teardown»). Utiliza la argumento enter para distinguir entre las dos.
También puedes importar este señal desde django.core.signals para evitar importar de django.test en situaciones no de prueba.
Argumentos enviados con este señal:
El manipulador de configuración.
settingEl nombre del parámetro de configuración.
valueEl valor del parámetro de configuración después del cambio. Para los parámetros que inicialmente no existen, en la fase «teardown», value es None.
enterUn booleano; True si el parámetro se aplica, False si se restaura.
template_rendered¶Se envía cuando el sistema de prueba renderiza un template. Esta señal no se emite durante la operación normal de un servidor Django – solo está disponible durante las pruebas.
Argumentos enviados con este señal:
Señales enviadas por el envoltorio de la base de datos cuando se inicia una conexión a la base de datos.
Se envía cuando el envoltorio de la base de datos establece la conexión inicial a la base de datos. Esto es particularmente útil si deseas enviar cualquier comando posterior a la conexión al back-end SQL.
Argumentos enviados con este señal:
La clase de envoltura del base de datos – es decir, django.db.backends.postgresql.DatabaseWrapper o django.db.backends.mysql.DatabaseWrapper, etc.
connectionLa base de datos que se ha abierto. Esto puede usarse en una configuración de bases de datos múltiples para diferenciar señales de conexión de diferentes bases de datos.
may 31, 2026