Produits Entr'ouvert » Passerelle

Il faut invalider le cache quand on peut le faire, typiquement lors de update_coordinates (sinon la personne qui envoie un changement de son 06 ou de son mail ne verra pas le changement sur sa page d'information avant une heure, et ne va pas comprendre)

Nicolas Roche a écrit :

J'ai mis juste 5 minutes de cache pour limiter les soucis.

Yep, c'est mieux.

Une solution plus stable serait de retirer le paramètre school_year de get_family_data
qui n'est pas utilisé par les autres endpoints.

On sait jamais, ça pourrait être utile, c'est paramètre de readFamily il aura peut-être son heure de gloire.

Ce qu'il faut c'est mettre en cache un dictionnaire {2020: données-de-2020, 2021: données-de-2021, ...} dans une clé maelis-family-data-<family_id>. C'est alors facile de tout invalider (supprimer la clé), et c'est juste pour la recherche et mise à jour du cache qu'il faut être (très légèrement) inventif.

La meilleure solution je pense c'est d'avoir un cache à deux niveaux comme Nicolas a commencé à le faire, mais y stocker un préfixe plutôt qu'une liste de clés.

def invalidate_cache(self, family):
   cache.delete('family-cache-%s' % family.id)

def get_family_cache_prefix(self, family, set=False):
   cache_prefix_key = 'family-cache-prefix-%s' % family.id
   cache_prefix = cache.get(cache_prefix_key)
   if not cache_prefix:
      cache_prefix = uuid.uuid4().hex
      if set:
          cache.set(cache_prefix_key, cache_prefix)
   return cache_prefix

def get_from_cache(self, family, key):
   return cache.get('family-cache-%s-%s' % (get_family_cache_prefix(family), key)

def set_to_cache(self, family, key):
   return cache.set('family-cache-%s-%s' % (get_family_cache_prefix(family, set=True), key)

C'est plus stable que de jouer avec des dicos ou des listes dans le cache. À noter que parce que notre cache n'est pas partagé si les utilisateurs ne tapent sur le même noeud pour combo et w.c.s, il peut y avoir des incohérences (combo.node1 tapant sur passerelle.node1 et son cache et wcs.node2 sur l'autre, ou alors si les noeuds n'ont pas de préférence entre eux c'est pire); je ne sais pas si c'est possible ou si haproxy redirige une IP toujours sur le même noeud pour toutes les briques.

Pour ces cas là je pense qu'on pourrait se permettre un cache en base (vu qu'on vise à palier les latences du WS ce sera toujours beaucoup plus rapide depuis la base SQL). Mais c'est à pour un autre ticket.

Aussi les méthodes pourrait être posé au niveau de BaseResource qu'on arrête d'implémenter des caches différents dans tous les connecteurs (et si on améliore quelque chose ça bénéficiera à tous).

(je laisse ça dans les mains de benj, ça me semble délirant)