2010-12-23 6 views
6

Acabo de configurar nuestro sitio de desarrollo Django para usar redis para un backend de caché y todo estaba funcionando bien. Bajé Redis para ver qué pasaría, y por supuesto Django 404 debido al comportamiento de back-end de la memoria caché. O se rechazó la conexión, o varios otros errores.¿Hay alguna forma de ignorar los errores de caché en Django?

¿Hay alguna manera de ordenar a Django que ignore los errores de caché y continúe el proceso de la manera normal? Parece raro que el almacenamiento en caché sea una optimización del rendimiento, pero puede derribar todo un sitio si falla.

Traté de escribir una envoltura alrededor del backend de este modo:

class CacheClass(redis_backend.CacheClass): 
    """ Wraps the desired Cache, and falls back to global_settings default on init failure """ 
    def __init__(self, server, params): 
     try: 
      super(CacheClass, self).__init__(server, params) 
     except Exception: 
      from django.core import cache as _ 
      _.cache = _.get_cache('locmem://') 

Pero eso no funcionará, ya que estoy tratando de establecer el tipo de caché en la llamada que establece el tipo de caché. Todo es un gran desastre.

Entonces, ¿hay alguna manera fácil de tragar los errores de caché? ¿O para configurar el backend de caché predeterminado en caso de falla?

Respuesta

0

No parece que haya alguna buena manera de hacer lo que quiera, sin error de escritura que se transfiere directamente a los métodos que admite el backend de caché. Incluso si el init del backend falla, algunos backends solo arrojarán errores en el primer acceso al back-end.

Lo que he hecho es modificar el backend para ajustar todos los métodos con el manejo de errores que es condicional en un parámetro pasado al constructor. No es tan lindo como me gustaría ... pero es lo menos intrusivo.

No es necesario cambiar nada en el código de llamada, por lo que la interfaz, si se quiere, se mantiene.

0

no he usado, pero aquí hay un fragmento de Django que pretende ofrecer un motor de caché con una función de retorno: http://djangosnippets.org/snippets/2193/

+0

gracias por el enlace, pero que permite soportar múltiples backends. El código de manejo de errores todavía tendría que ir a alguna parte, y lo que busco es eliminarlo de la persona que llama. –

+0

Pensé que su función de respaldo tenía potencial para cumplir su objetivo de "establecer el backend de caché predeterminado en caso de falla". ¿No? –

+0

No realmente. Esa implementación solo 'retrocede' si no se puede recuperar un valor de la memoria caché. No, dónde maneja los errores. Mi especificación original estaba desactivada de todos modos, ya que la falla puede ocurrir después de init. Establecer un nuevo back-end en ese punto no parece razonable a menos que se maneje específicamente dentro del back-end. –

1

Mira django-cache-repliegue:

https://pypi.python.org/pypi/django-cache-fallback/0.2.1

CACHES = { 
    # Set default cache to FallbackCache 
    'default': { 
     'BACKEND': 'cache_fallback.FallbackCache', 
    }, 
    # Your production main cache (Redis, for example) 
    'main_cache': { 
     'BACKEND': 'redis_lock.django_cache.RedisCache', 
     'LOCATION': redis_url, 
     'OPTIONS': { 
      'CLIENT_CLASS': 'django_redis.client.DefaultClient', 
     }, 
     'TIMEOUT': 500, 
    }, 
    # Use dummy cache to ignore main cache errors and get data from DB 
    'fallback_cache': { 
     'BACKEND': 'django.core.cache.backends.dummy.DummyCache', 
    } 
} 
Cuestiones relacionadas