Wie erzwinge ich, dass Jinja2-Vorlagen neu kompiliert werden?

Question

Ich versuche, Jinja2 Vorlage in der Django App zu wechseln, ohne die Anwendung neu zu starten.

Hat jemand das getan? Grundsätzlich muss ich jinja2 zwingen, die Vorlagen neu zu laden, sobald die Änderung der Hautauswahl angewendet wird.

Ich habe versucht, Cache-Objekt auf der Vorlage Umgebungsobjekt ohne Wirkung neu zu erstellen.

myskin_utils.py:

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

Ich habe auch versucht, das Modul zu laden, die meine ENV_OBJECT mit

reload(myskin) #also no effect on the output 

enthält Eine andere Sache, die ich on the fly ändern möchte ist die Sprache, aber ich denke, es ist eine separate Frage.

Vielen Dank für jeden Hinweis.

edit: Ich habe keine Cache mit jinja2 einrichten, aber ich habe eine Geschwindigkeit von bis sehe Jinja verwenden, nachdem er von Django Vorlagen wechseln, ich vermute, dass Template-Bytecode in dem kompilierten Code meiner Ansicht Funktionen lebt aber Ich habe nicht in Details von Jinja geschaut.

Ich habe ENV (eine Instanz von CoffinEnvironment die Environment Jinja der Unterklassen) im globalen Namensraum eines View-Modul importiert und ruft ENV.get_template() Innenansicht Funktionen (Django + Coffin + Jinja2).

gefunden, dass, wenn ich reload() builtin auf meiner Umgebung Modul innerhalb die View-Funktion der Template-Switch macht den Python nennen, aber ich würde nicht, dass Code in jede Funktion bleiben mag.

Answer 1

Standardmäßig verwendet Jinja2 überhaupt kein Caching, aber es wird empfohlen, ein Caching-Backend zu konfigurieren, um die Dinge ein wenig zu beschleunigen. Damit muss jinja2 nicht jede Vorlage bei jeder Anfrage analysieren und kompilieren. Jinja2 unterstützt derzeit 2 verschiedene Cache-Typen:

Eine davon ist FileSystemBytecodeCache, die (wie der Name schon sagt) Datei basiert. Daher werden alle kompilierten Vorlagen im Dateisystem gespeichert und von dort abgerufen. Wenn Sie sich die Implementierung genau ansehen, finden Sie dort auch eine cache.clear() Methode, die einfach alle Dateien in diesem temporären Ordner löscht. Veranlassen, dass alle Vorlagen erneut analysiert/kompiliert werden. Der andere Cache-Typ ist ein MemcachedBytecodeCache, der nur ein dünner Wrapper für Memcache ist. Diese Methode wird empfohlen, da Memcache alles im Speicher speichert, also ein bisschen schneller ist als die Festplatte, und Sie können denselben Cache von verschiedenen Hosts verwenden (was nützlich ist, wenn Sie eine Art Cluster ausführen). Der zugrunde liegende Memcache-Client (entweder werkzeug.contrib.cache, python-memcached oder cmemcache) stellt auch eine clear()-Methode bereit, die alles im Cache löscht. Da Sie den Cache aber wahrscheinlich auch für andere Zwecke verwenden (z. B. Speichern des Ergebnisses von teuren Datenbankabfragen), wird die Methode clear() in jinja nicht angezeigt, da sie sich auf alles (und nicht nur auf die Vorlagen) auswirkt.

Also, um Ihre Optionen zu fassen sind:

• Verwenden Jinja2 ohne Cache
• Verwenden Jinja2 mit einem FileSystemBytecodeCache und rufen cache.clear()
• Verwenden Jinja2 mit einem MemcachedBytecodeCache und rufen memcache_client.clear() (was auch klar, alles andere im Cache).
• Führen Sie einen separaten memcached-Prozess auf einem anderen Port aus, der nur mit Jinja2 verwendet wird. Dann rufen Sie memcache_client.clear() und alle Vorlagen werden gelöscht.

Answer 2

Das ist falsch. Jinja verwendet standardmäßig einen LRUCache im Speicher-Cache von cache_size (Environment-Parameter). Sie können einen Disk-Cache verwenden, um nachfolgende Neustarts der App ebenfalls durchzuführen (keine Neukompilierung erforderlich).