Pensé que había una respuesta fácil a esto en las versiones recientes de Django, pero no puedo encontrarla.
Tengo un código que toca la base de datos. Quiero que se ejecute cada vez que se inicia Django. Me parece que tengo dos opciones:
Opción 1. AppConfig.ready() : funciona, pero también se ejecuta antes de que se hayan creado las tablas de la base de datos (es decir, durante las pruebas o al reiniciar la aplicación sin datos). Si uso esto, tengo que detectar varios tipos de excepciones y adivinar que la causa es una base de datos vacía:
def is_db_init_error(e, table_name): return ("{}' doesn't exist".format(table_name) in str(e) or "no such table: {}".format(table_name) in str(e) ) try: # doing stuff except Exception as e: if not is_db_init_error(e, 'foo'): raise else: logger.warn("Skipping updating Foo object as db table doesn't exist") Opción 2. Use post_migrate.connect(foo_init, sender=self) , pero esto solo se ejecuta cuando hago una migración.
Opción 3. A la antigua, llámalo desde urls.py Quería mantener cosas como esta fuera de urls.py y pensé que AppConfig era el único camino verdadero.
Hasta ahora me he conformado con la opción 2: no me gustan las cosas malolientes de prueba/excepto en la opción 1 y la opción 3 me molesta ya que urls.py se convierte en un vertedero.
Sin embargo, la Opción 2 a menudo me hace tropezar cuando estoy desarrollando localmente; debo recordar ejecutar migraciones cada vez que quiero que se ejecute mi código de inicio. Cosas como bajar una base de datos de producción o similar a menudo causan problemas porque las migraciones no se activan.
Sugeriría la señal connection_created , que es:
Enviado cuando el contenedor de la base de datos realiza la conexión inicial a la base de datos. Esto es particularmente útil si desea enviar comandos posteriores a la conexión al backend de SQL.
Por lo tanto, ejecutará el código de la señal cuando la aplicación se conecte a la base de datos al comienzo del ciclo de la aplicación.
También funcionará dentro de una configuración de base de datos múltiple e incluso separará las conexiones realizadas por la aplicación en la inicialización:
conexión
La conexión de base de datos que se abrió. Esto se puede usar en una configuración de múltiples bases de datos para diferenciar las señales de conexión de diferentes bases de datos.
Nota:
Es posible que desee considerar el uso de una combinación de señalespost_migrate y connection_created mientras verifica dentro de su AppConfig.ready() si ocurrió una migración (por ejemplo, marque la activación de una señal post_migrate ):
from django.apps import AppConfig from django.db.models.signals import post_migrate, connection_created # OR for Django 2.0+ # django.db.backends.signals import post_migrate, connection_created migration_happened = false def post_migration_callback(sender, **kwargs): ... migration_happened = true def init_my_app(sender, connection): ... class MyAppConfig(AppConfig): ... def ready(self): post_migrate.connect(post_migration_callback, sender=self) if !migration_happened: connection_created.connect(init_my_app, sender=self)En Django >= 3.2, la señal post_migrate se envía incluso si no se ejecutan migraciones, por lo que puede usarla para ejecutar el código de inicio que se comunica con la base de datos.
https://docs.djangoproject.com/en/3.2/ref/signals/#post-migrate
Enviado al final de la migración (incluso si no se ejecutan migraciones) y comandos de vaciado. No se emite para aplicaciones que carecen de un módulo de modelos.
Los controladores de esta señal no deben realizar alteraciones en el esquema de la base de datos, ya que hacerlo puede provocar que el comando de vaciado falle si se ejecuta durante el comando de migración.