Jinja: os modelos importados estão sendo armazenados em cache por muito tempo

Criado em 16 jul. 2013 · 4Comentários · Fonte: pallets/jinja

Eu tenho um modelo chamado main.html. Ele {% importa %} um módulo chamado module_a (sem contexto). module_a {% importa %} module_b da mesma forma.

Quando mudo module_a, o carregador de modelo reconhece isso e o recarrega.

Quando mudo module_b, o carregador de template não o reconhece. Tenho que reiniciar o processo.

Acredito que isso se deva ao fato de que o código gerado para module_a faz as importações em sua função root(). get_template vê que module_a está atualizado, então não o recarrega, então não executa novamente sua função root().

Não tenho certeza de como lidar com isso. Obviamente, chamar root() em cada chamada para get_template é ruim. A solução mais completa seria acompanhar as dependências de cada modelo, mas isso dá muito trabalho.

Fonte

glasserc

👍3

Comentários muito úteis

O problema é que as importações são armazenadas em cache, mas não rastreadas. Não tenho certeza de qual seria a melhor maneira de lidar com isso.

mitsuhiko em 25 out. 2016

👍4 👎1

Todos 4 comentários

Estamos passando por isso também. (Eu quase não encontrei esse bug porque você não usou o termo auto_reload -- isso só é relevante quando auto_reload=True ).

Parece que isso seria bastante complicado de corrigir; idealmente, você gostaria que o método uptodate retornasse de get_source para verificar não apenas o próprio arquivo de origem, mas também qualquer arquivo de origem importado, estendido ou incluído. Mas no momento em que uptodate é definido, tudo o que você tem é a fonte bruta não analisada, para que a informação não esteja disponível.

Pode ser implementável em um nível mais alto (por exemplo, em Template.is_up_to_date ), mas parece que também exigiria uma cirurgia significativa para obter as informações de dependência do compilador.

carljm em 16 jul. 2014

Acabei de me deparar com isso também. Isso é muito chato no desenvolvimento porque significa que eu tenho que definir cache_size para 0, e então as coisas ficam muito lentas (como se poderia esperar).

Vou tentar cavar os internos para ver se acho alguma coisa. Enquanto isso, se alguém com mais experiência puder sugerir uma solução ou até mesmo alguma direção, seria muito bom!

k4nar em 25 out. 2016

👍3

O problema é que as importações são armazenadas em cache, mas não rastreadas. Não tenho certeza de qual seria a melhor maneira de lidar com isso.

mitsuhiko em 25 out. 2016

👍4 👎1

Ok, então o problema aqui não é com o cache do template, mas com o cache de variáveis passadas para as macros importadas.
(Ao menos em meu caso)

Minha solução foi usar um método que retorna meus valores de contexto atualizados para serem renderizados.

No meu cenário eu estava fazendo uma macro para paginação. A macro precisava do objeto de solicitação.

abordagem inicial dentro da macro
{% set pagenum, limit = request.args.pg , request.args.limit %}
Isso funcionará inicialmente, mas em solicitações subsequentes os valores de contexto de macro são armazenados em cache para sempre, a menos que um servidor seja reinicializado

abordagem de trabalho dentro da macro
{% set pagenum, limit = request.get_params() %}
Isso agora retornará meus parâmetros de solicitação atualizados em cada chamada sem sacrificar o cache de minhas macros.

Também notei que o cache das macros tem uma velocidade de ~ 2,5 x nos meus tempos de resposta.
Sem cache ~= 450ms
Com cache ~= 150ms