开发者

How to force Jinja2 templates to recompile?

开发者 https://www.devze.com 2023-01-25 11:20 出处:网络
I\'m trying to switch Jinja2 template in the django app without restarting the application. Has anyone done this? Basically I need to force jinja2 to reload the templates once the skin selection cha

I'm trying to switch Jinja2 template in the django app without restarting the application.

Has anyone done this? Basically I need to force jinja2 to reload the templates once the skin selection change is applied.

I've tried to re-create cache object on the template environment object with no effect.

myskin_utils.py:

from jinja2.environment import create_cache
ENV_OBJECT.cache = create_cache(50)

I've also tried to reload the module that contains my ENV_OBJECT with

reload(myskin开发者_JAVA百科) #also no effect on the output

Another thing I'd like to change on the fly is language, but I guess it's a separate question.

Thanks for any advice.

edit: I don't have cache set up with jinja2, but I do see a speed up from using Jinja after switching from Django templates, I suspect that template bytecode lives in the compiled code of my view functions but I did not look into details of jinja.

I have ENV (an instance of CoffinEnvironment which subclasses Jinja's Environment) imported in the global namespace of a view module and calls ENV.get_template() inside view functions (Django+Coffin+Jinja2).

Found that if I call python's reload() builtin on my environment module within the view function the template does switch, but I would not like to stick that code into every function.


Per default Jinja2 doesn't use any caching at all, but it's recommended to configure a caching backend to speed things up a little bit. So that jinja2 doesn't have to parse and compile every template on every requests. Jinja2 supports currently 2 different cache types out of the box:

One of them is FileSystemBytecodeCache which is (like the name suggests) file based. So all compiled templates are stored on the file system and retrieved from there. If you look closely at the implementation, you will also find a cache.clear() method there which simply deletes all files in this temporary folder. Causing all templates to be parsed/compiled again.

The other cache type is a called MemcachedBytecodeCache which is just a thin wrapper for Memcache. This method is recommended, because Memcache stores everything in memory, so it's a little bit faster than hitting the disk, and you can use the same cache from different hosts (which is useful if you are running some kind of cluster).

The underlying Memcache client (either werkzeug.contrib.cache, python-memcached or cmemcache) does also provide a clear() method which will delete everything inside the cache. But because you probably use the cache for other things too (e.g. storing the result of expensive database queries there), the clear() method isn't exposed in jinja, because it will affect everything (and not just the templates).

So, to summarize your options are:

  • Use Jinja2 without a Cache
  • Use Jinja2 with a FileSystemBytecodeCache and call cache.clear()
  • Use Jinja2 with a MemcachedBytecodeCache and call memcache_client.clear() (which will also clear everything else in the cache).
  • Run a separate memcached process on another port which is only used with Jinja2. Then call memcache_client.clear() and all templates will be cleared.


This is wrong. Jinja uses a LRUCache in memory cache by default, of cache_size (Environment parameter). You can use a disk cache to make subsequent restarts of the app preformant too (no recompilation needed).

0

精彩评论

暂无评论...
验证码 换一张
取 消