Je viens de définir notre site de développement Django pour utiliser Redis pour un backend de cache et tout allait bien travailler. J'ai ramené Redis pour voir ce qui se passerait, et bien sûr, suffisamment de Django 404 est dû au comportement du cache. Soit la connexion a été refusée, soit diverses autres erreurs.
Y a-t-il un moyen d'instruire Django d'ignorer les erreurs de cache et de continuer à traiter la voie normale? Il semble étrange que la mise en cache soit une optimisation de la performance, mais peut abattre un site entier s'il échoue. P>
J'ai essayé d'écrire une enveloppe autour du backend comme: P>
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://')
3 Réponses :
Je ne l'ai pas utilisé, mais voici un extrait de Django qui prétend fournir un backend de cache avec une fonction de secours: http://djangosnippets.org/snippets/2193/ p>
Merci pour le lien, mais permettant de supporter plusieurs backends. Le code de traitement des erreurs aurait toujours besoin d'aller quelque part - et la suppression de l'appelant est ce que je suis après.
Je pensais que sa fonctionnalité de seconde était potentielle de répondre à votre objectif de "définir le backend de cache par défaut sur l'échec". Non?
Pas vraiment. Cette mise en œuvre ne fait que "revenir" si une valeur ne peut pas être extraite du cache. NON D'où traite-t-il des erreurs. Ma spécification d'origine était éteinte de toute façon, comme l'échec peut se produire après init. Définir un nouveau backend à ce moment-là semble déraisonnable, sauf si elle est traitée spécifiquement dans le backend lui-même.
On ne semble pas que ce soit un bon moyen de faire ce que je veux, sans écriture d'erreur qui remonte directement dans les méthodes du support du cache. Même si l'init du backend échoue, certains backends ne lanceront que des erreurs sur le premier accès au backend. P>
Ce que j'ai fait est modifié le backend pour envelopper toutes les méthodes avec une manipulation des erreurs qui est conditionnelle sur un paramètre transmis au constructeur. Pas aussi gentil que je voudrais .. mais c'est le moins intrusif. p>
Rien ne doit changer dans le code d'appel, donc l'interface, si vous voulez, est maintenue. P>
regarder https://pypi.python.org/pypi/django-cache-fallback/0.2.1 p>