Jinja: 가져온 템플릿이 너무 오랫동안 캐시되고 있습니다.

우리도 이 문제에 직면해 있습니다. ( auto_reload 라는 용어를 사용하지 않았기 때문에 이 버그를 거의 찾지 못했습니다. 이것은 auto_reload=True 때만 관련이 있습니다.)

이것은 수정하기가 상당히 까다로울 것 같습니다. 이상적으로는 get_source uptodate 메서드를 사용하여 소스 파일 자체뿐만 아니라 가져오거나 확장하거나 포함하는 모든 소스 파일도 확인해야 합니다. 그러나 uptodate 가 정의된 시점에서는 구문 분석되지 않은 원시 소스만 있으므로 해당 정보를 사용할 수 없습니다.

더 높은 수준(예: Template.is_up_to_date )에서 구현할 수 있지만 컴파일러에서 종속성 정보를 다시 가져오려면 상당한 수술이 필요한 것처럼 보입니다.

나도 방금 이것에 부딪쳤다. 이것은 cache_size 를 0으로 설정해야 한다는 것을 의미하기 때문에 개발에서 꽤 성가신 일입니다.

내부를 파헤쳐보고 뭔가가 떠오르지 않는지 확인하려고 합니다. 그 동안 더 많은 경험을 가진 누군가가 솔루션이나 방향을 제안할 수 있다면 정말 좋을 것입니다!

문제는 가져오기가 캐시되지만 추적되지 않는다는 것입니다. 이 문제를 처리하는 가장 좋은 방법이 무엇인지 잘 모르겠습니다.

자, 여기서 문제는 템플릿의 캐싱이 아니라 가져온 매크로에 전달된 변수의 캐싱에 있습니다.
(적어도 내 경우에는)

내 해결 방법은 렌더링할 업데이트된 컨텍스트 값을 반환하는 메서드를 사용하는 것이었습니다.

내 시나리오에서는 페이지 매김을 위한 매크로를 만들고 있었습니다. 매크로에는 요청 개체가 필요했습니다.

매크로 내 초기 접근
{% set pagenum, limit = request.args.pg , request.args.limit %}
이것은 처음에는 작동하지만 후속 요청에서 매크로 컨텍스트 값은 서버가 재부팅되지 않는 한 영원히 캐시됩니다.

매크로 내 작업 방식
{% set pagenum, limit = request.get_params() %}
이제 매크로 캐싱을 희생하지 않고 모든 호출에서 업데이트된 요청 매개변수를 반환합니다.

또한 매크로를 캐싱하면 응답 시간이 ~2.5배 빨라진다는 사실도 알게 되었습니다.
캐싱 없이 ~= 450ms
캐싱 포함 ~= 150ms