Produits Entr'ouvert » Passerelle

On pourrait commencer en simplement autorisant un paramètre de cache qui soit un entier ? (pour moi ça pourrait même s'arrêter là)

Oui sur BaseRessource ? Après pour les connecteurs spécifiques, style IWS, ça peut être intéressant de pouvoir donner une valeur par défaut qui ne soit pas 0 parce qu'on sait que ce sera toujours lent mais là en même temps comme la clé du cache dépendra de la requête je me dis que ce n'est de toute façon pas pertinent d'avoir quelque chose de global, et je retire tout ce que je dis.

Je parlais d'un paramètre à @endpoint(), plutôt que permettre cache_settings='MY_CONNECTOR_CACHE_DURATION' permettre cache_duration=300.

Frédéric Péters a écrit :

On pourrait commencer en simplement autorisant un paramètre de cache qui soit un entier ? (pour moi ça pourrait même s'arrêter là)

Je suis partis sur un settings pour pouvoir facilement modifier les paramètres du cache dans les tests unitaires où à priori on ne voudra jamais de cache (et aussi pour ne pas avoir à faire une release de passerelle juste pour changer une durée de cache). Dans l'idée que dans les settings de tests on ne définira jamais de MY_CONNECTOR_CACHE_DURATION et voilà (et si vraiment on en veut, la fixture settings de pytest doit faire l'affaire).

Si on passe directement un entier à endpoint, comment on désactive le cache dans les tests ? Peut-être à coups de monkeypatch du endpoint_info ... ça s'annonce un peu pénible.

Alternativement peut-être normaliser le nom du settings : "CACHE_NOM_DU_CONNECTEUR_NOM_DU_ENPOINT", et du coup ne même plus passer de paramètre à endpoint, juste aller examiner la présence du settings concerné dans dispatch ?

Je préfère vraiment un cache_duration=300, quitte à ce que le endpoint indique cache_duration=self.cache_duration, qui viendra de l'attribut du modèle (facile à modifier pour un test), ou même d'un IntegerField qui serait alors paramétrable dans l'UI lorsqu'on instancie le connecteur. Du grand n'importe quoi, oubliez-moi.

Emmanuel Cazenave a écrit :

Je suis partis sur un settings pour pouvoir facilement modifier les paramètres du cache dans les tests unitaires où à priori on ne voudra jamais de cache

Pour ça il y a en fait 'django.core.cache.backends.dummy.DummyCache' qui fait semblant mais qui ne cache rien.

Reste mon argument "ne pas faire une release de passerelle pour changer une durée de cache".

Je vais faire mon lourd mais que est le cas d'usage ? Les données quasi statiques (référentiels) ?

Mon cas d'usage c'est IWS : demandes de dates disponibles pour un rendez-vous.
Un endpoint de connecteur qui renvoie des donnés au format data source pour pouvoir être branché sur un champ liste.
Je ne connais pas le mécanique de WCS, mais en tous cas il fait beaucoup d'appels pour une même demande.

Et donc non pas référentiel, parce que les dates disponibles dépendent en théorie de paramètres genre ville , adresse, type de demande, etc...

Donc tu fais des GET /iws/my-slug/get-dates/?ville=xxx&type_de_demande=12&guid=<form_number/form_uuid>&etc... et tu veux que ce soit mis en cache pour toujours pour que pour un même guid tu reçoives toujours le même token (ou plutôt que pour 2 guid différents tu ne reçoives jamais le même token).

La clé de cache ce serait un hash de request.get_full_path() ?

Je continue à penser que ça pourrait très bien aller dans le code de datasource pourvu qu'on utilise comme clé de cache l'URL de destination, et ça risque de resservir immédiatement (genre pour SOLIS je crois).

Pour être précis, je propose d'en faire une option de la définition de la datasource, cache_duration, bien sûr ça ne marchera pas pour les sources JSONP jusqu'à ce qu'on ait un proxy dans w.c.s.

Benjamin Dauvergne a écrit :

Donc tu fais des GET /iws/my-slug/get-dates/?ville=xxx&type_de_demande=12&guid=<form_number/form_uuid>&etc... et tu veux que ce soit mis en cache pour toujours pour que pour un même guid tu reçoives toujours le même token (ou plutôt que pour 2 guid différents tu ne reçoives jamais le même token).

Je pensais à 5 min de cache plutôt que "pour toujours", le temps de remplir une demande quoi, juste pour pas retaper dans le webservice métier
quand on valide la page de formulaire, puis quand on soumet la demande.

La clé de cache ce serait un hash de request.get_full_path() ?

Dans ce que je propose c'est le cache_page de django qui crée la clé, mais il fait un truc dans ce gout là oui.

Je continue à penser que ça pourrait très bien aller dans le code de datasource pourvu qu'on utilise comme clé de cache l'URL de destination, et ça risque de resservir immédiatement (genre pour SOLIS je crois).

Je connais absolument pas ce code, je me déclare incompétent.

Et donc pas moyen d'accéder à la façon dont est générée la clé de cache, il faudrait donc redéfinir un truc à la django.views.decorators.cache.cache_page qui lui même utilise django.middleware.cache.CacheMiddleware à redéfinir aussi,
c'est à ce niveau qu'on accède à la génération de la clé.

Bref assez lourdingue, pour faire quasiment la même chose à très peu de choses près.

Dommage que timestamp et signature soient dans la query string, dans des headers on aurait été bons.

Plutôt qu'essayer de profiter d'un décorateur de cache de django, gérer ça "manuellement" dans le perform de GenericEndpointView ?

Genre vaguement cette trame :

-        return self.endpoint(request, **self.get_params(request, *args, **kwargs))
+        params = self.get_params(request, *args, **kwargs)
+        if method == 'GET' and self.endpoint.cache_duration:
+            cache_key = hashlib.md5(repr(self.endpoint) + repr(params)).hexdigest()  # me semble suffisant, à vérifier
+            if ... has cache:  return ...
+        result = self.endpoint(request, params)
+        if method == 'GET' and self.endpoint.cache_duration:
+             pass  # mise en cache
+        return result

et laissé de coté le tests sur request.GET, perform étant appelé uniquement dans get.

Sauf que :

    def post(self, request, *args, **kwargs):
        return self.get(request, *args, **kwargs)

Côté tests, je préférerais ne pas toucher à passerelle/contrib/stub_invoices/models.py, cette méthode de test pourrait être ajoutée par monkeypatch dans le test ?