Te sugerimos que revises esta respuesta en un entorno controlado antes de enviarlo a producción, un saludo.
Solución:
Es una mala práctica poner código en settings.py aparte de las asignaciones. Es más adecuado como comando de administración:
from django.core.management.base import BaseCommand
from django.core.cache import cache
class Command(BaseCommand):
def handle(self, *args, **kwargs):
cache.clear()
self.stdout.write('Cleared cachen')
Que puede agregar a su proyecto pegándolo someapp/management/commands. Por ejemplo, podrías crear una nueva aplicación llamada utils y agrega eso a tu INSTALLED_APPS y la estructura del directorio se vería así:
utils
├── __init__.py
└── management
├── __init__.py
└── commands
├── __init__.py
└── clearcache.py
Ahora puede borrar el caché haciendo ./manage.py clearcache. Si desea ejecutar clearcache cada vez que ejecute el servidor, puede escribir un alias de shell para hacerlo:
alias runserver='./manage.py clearcache && ./manage.py runserver'
Alternativamente, creo que puede escribirlo como un script independiente y configurar los ajustes que requiere a mano:
from django.conf import settings
# obviously change CACHES to your settings
CACHES =
'default':
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'unique-snowflake'
settings.configure(CACHES=CACHES) # include any other settings you might need
from django.core.cache import cache
cache.clear()
Escribir su secuencia de comandos independiente de esta manera evitará las importaciones circulares y le permitirá importarlo desde su configuración.py. Aunque no hay garantía de que settings.py se importe solo una vez, por lo que, en general, evitaría esto. Sería bueno si el marco de la señal pudiera disparar un evento una vez cada vez que se inicia la aplicación, después de que se cargan las configuraciones para cosas como esta.
Django Extensions te permite borrar el caché a través de
manage.py clear_cache
más información y muchos más comandos en sus documentos.
normalmente solamente No quiere invalidar sus cachés si el código cambia de una manera que requiere un nuevo caché. No en cada reiniciar.
Esto se maneja mejor usando la función Django: settings.CACHES.VERSIONy aumente ese número cada vez que cambie el código que cambia el formato de los datos almacenados en caché. De esa manera, en una implementación, usará automáticamente una memoria caché nueva cuando implemente un código nuevo, pero mantendrá la memoria caché si su código es compatible con la memoria caché con el código anterior.
Si tienes algún recelo y forma de mejorar nuestro post eres capaz de añadir una ilustración y con gusto lo estudiaremos.