Jinja: les modèles importés sont mis en cache trop longtemps

Créé le 16 juil. 2013 · 4Commentaires · Source: pallets/jinja

J'ai un modèle appelé main.html. Il {% importe %} un module appelé module_a (sans contexte). module_a {% importe %} module_b de la même manière.

Lorsque je change module_a, le chargeur de modèles le reconnaît et le recharge.

Lorsque je change module_b, le chargeur de modèles ne le reconnaît pas. Je dois recommencer le processus.

Je pense que cela est dû au fait que le code généré pour module_a effectue les importations dans sa fonction root(). get_template voit que module_a est à jour, donc ne le recharge pas, donc ne relance pas sa fonction root().

Je ne sais pas comment résoudre ce problème. Évidemment, appeler root() à chaque appel à get_template est mauvais. La solution la plus complète serait de garder une trace des dépendances de chaque modèle, mais c'est beaucoup de travail.

Source

glasserc

👍3

Commentaire le plus utile

Le problème est que les importations sont mises en cache mais pas suivies. Je ne sais pas quelle serait la meilleure façon de gérer cela.

mitsuhiko le 25 oct. 2016

👍4 👎1

Tous les 4 commentaires

Nous nous heurtons également à cela. (J'ai failli ne pas trouver ce bogue parce que vous n'avez pas utilisé le terme auto_reload -- cela n'est pertinent que lorsque auto_reload=True ).

Il semble que ce serait assez difficile à résoudre; idéalement, vous voudriez que la méthode uptodate renvoyée par get_source vérifie non seulement le fichier source lui-même, mais également tout fichier source qu'il importe, étend ou inclut. Mais au moment où uptodate est défini, tout ce que vous avez est la source brute non analysée, de sorte que l'information n'est pas disponible.

Il pourrait être implémentable à un niveau supérieur (par exemple dans Template.is_up_to_date ) mais cela semble nécessiter également une intervention chirurgicale importante pour récupérer les informations de dépendance du compilateur.

carljm le 16 juil. 2014

Je viens de tomber sur ça aussi. C'est assez ennuyeux dans le développement car cela signifie que je dois définir cache_size sur 0, puis les choses deviennent très lentes (comme on pouvait s'y attendre).

Je vais essayer de creuser dans les internes pour voir si je trouve quelque chose. En attendant, si quelqu'un avec plus d'expérience pouvait suggérer une solution ou même une direction, ce serait vraiment génial !

k4nar le 25 oct. 2016

👍3

Le problème est que les importations sont mises en cache mais pas suivies. Je ne sais pas quelle serait la meilleure façon de gérer cela.

mitsuhiko le 25 oct. 2016

👍4 👎1

Ok, donc le problème ici n'est pas avec la mise en cache du modèle mais la mise en cache des variables passées dans les macros importées.
(du moins dans mon cas)

Ma solution de contournement consistait à utiliser une méthode qui renvoie mes valeurs de contexte mises à jour à rendre.

Dans mon scénario, je faisais une macro pour la pagination. La macro avait besoin de l'objet de requête.

approche initiale au sein de la macro
{% set pagenum, limit = request.args.pg , request.args.limit %}
Cela fonctionnera initialement, mais lors des requêtes suivantes, les valeurs de contexte de macro sont mises en cache pour toujours à moins qu'un serveur ne redémarre

approche de travail au sein de la macro
{% set pagenum, limit = request.get_params() %}
Cela renverra désormais mes paramètres de requête mis à jour à chaque appel sans sacrifier la mise en cache de mes macros.

J'ai également remarqué que la mise en cache des macros a une vitesse d'environ 2,5 fois supérieure dans mes temps de réponse.
Sans mise en cache ~= 450ms
Avec mise en cache ~= 150ms