Jinja: las plantillas importadas se almacenan en caché durante demasiado tiempo

Creado en 16 jul. 2013 · 4Comentarios · Fuente: pallets/jinja

Tengo una plantilla llamada main.html. {% importa%} un módulo llamado module_a (sin contexto). module_a {% importa %} module_b de la misma manera.

Cuando cambio module_a, el cargador de plantillas lo reconoce y lo vuelve a cargar.

Cuando cambio module_b, el cargador de plantillas no lo reconoce. Tengo que reiniciar el proceso.

Creo que esto se debe al hecho de que el código generado para module_a realiza las importaciones en su función root(). get_template ve que module_a está actualizado, por lo que no lo vuelve a cargar, por lo que no vuelve a ejecutar su función root().

No estoy seguro de cómo abordar esto. Obviamente, llamar a root() en cada llamada a get_template es malo. La solución más completa sería realizar un seguimiento de las dependencias de cada plantilla, pero eso es mucho trabajo.

Fuente

glasserc

👍3

Comentario más útil

El problema es que las importaciones se almacenan en caché pero no se rastrean. No estoy seguro de cuál sería la mejor manera de lidiar con esto.

mitsuhiko en 25 oct. 2016

👍4 👎1

Todos 4 comentarios

Nos estamos topando con esto también. (Casi no encuentro este error porque no usaste el término auto_reload -- esto solo es relevante cuando auto_reload=True ).

Parece que esto sería bastante complicado de arreglar; lo ideal es que desee que el método uptodate devuelva get_source para verificar no solo el archivo fuente en sí, sino también cualquier archivo fuente que importe, amplíe o incluya. Pero en el momento en que se define uptodate , todo lo que tiene es la fuente sin analizar sin analizar, por lo que la información no está disponible.

Podría implementarse en un nivel superior (por ejemplo, en Template.is_up_to_date ), pero parece que también requeriría una cirugía significativa para recuperar la información de dependencia del compilador.

carljm en 16 jul. 2014

Acabo de encontrarme con esto también. Esto es bastante molesto en el desarrollo porque significa que tengo que establecer cache_size en 0, y luego las cosas se vuelven muy lentas (como era de esperar).

Trataré de indagar en el interior a ver si se me ocurre algo. Mientras tanto, si alguien con más experiencia pudiera sugerir una solución o incluso alguna dirección, ¡sería realmente genial!

k4nar en 25 oct. 2016

👍3

El problema es que las importaciones se almacenan en caché pero no se rastrean. No estoy seguro de cuál sería la mejor manera de lidiar con esto.

mitsuhiko en 25 oct. 2016

👍4 👎1

Bien, entonces el problema aquí no es el almacenamiento en caché de la plantilla, sino el almacenamiento en caché de las variables pasadas a las macros importadas.
(Al menos en mi caso)

Mi solución fue usar un método que devuelve mis valores de contexto actualizados para que se representen.

En mi escenario, estaba haciendo una macro para la paginación. La macro necesitaba el objeto de solicitud.

acercamiento inicial dentro de la macro
{% set pagenum, limit = request.args.pg , request.args.limit %}
Esto funcionará inicialmente, pero en solicitudes posteriores, los valores de contexto de macro se almacenan en caché para siempre a menos que se reinicie un servidor

enfoque de trabajo dentro de la macro
{% set pagenum, limit = request.get_params() %}
Esto ahora devolverá mis parámetros de solicitud actualizados en cada llamada sin sacrificar el almacenamiento en caché de mis macros.

También noté que el almacenamiento en caché de las macros tiene una aceleración de ~2.5x en mis tiempos de respuesta.
Sin almacenamiento en caché ~= 450ms
Con almacenamiento en caché ~= 150ms