Djangoには、キャッシュバックエンドとして様々な機構をサポートしています。

1. メモリキャッシュ
2. データベースキャッシュ
3. ファイルキャッシュ

また、バックエンドとは別に、キャッシュ化できるデータの単位も様々です。

• サイト全体をキャッシュ化
• ビュー単位でキャッシュ化
• テンプレートの一部をキャッシュ化
• オブジェクトの単位でキャッシュ化

特に「オブジェクト単位」でキャッシュ化できるため、原理的には変数ひとつだけをキャッシュデータ化することも可能で、まさに究極の粒度をもったキャッシュ機能であると言えます。

また、もっと上流のキャッシュ機能とDjangoベースのWebサーバーを連携させることも可能です。例えば、squidなどのProxyベースのキャッシュ機能との連携がそれに該当します。

まさに、なんでもあり、のDjangoキャッシュ機能ですが、今回はその中でも最も高速なメモリベースのキャッシュを中心に、キャッシュの設定方法を見ていきましょう。

Djangoでは、アプリ、context_processorsなど様々なプラグイン機能が提供されており、画一的なフレームワークの中でソフトウェアを実装することで効率化・高可搬性を実現しています。

しかし、一旦システムを実装開始すると、システムは様々な環境が依存しあうもので、一つの関数を書き換えると様々なビューやテンプレートファイルに修正範囲が波及する。。。なんてことがよく起こります。

せっかくMVCフレームワークを提供しているのに、それを正しく使わないのが悪い！などと怒られそうですが、理想と現実は異なる訳で、プラットフォームにはそのどちらもフォローできる柔軟な環境が求められます。

既存のシステム全てに共通で処理をフックしたり、テンプレート変数を追加したい。。。などということを実現するにはどうしたら良いのでしょうか？

これを簡単に実現できる方法がDjangoにはあります。
それがミドルウェアです。

Djangoには、テンプレートファイル内でのみ利用できるテンプレート変数と、グローバル変数のように、どのテンプレートファイルからも利用できるテンプレート変数も存在しています。

そのようなグローバル変数的なテンプレート変数のことをcontext_processorと呼びます。settings.pyにて、TEMPLATE_CONTEXT_PROCESSORS変数に、テンプレート変数を返すメソッドを登録しておくと、どのビューからでも当該変数をコンテキストに追加することが可能となります。

    $ emacs settings.py
      TEMPLATE_CONTEXT_PROCESSORS = (
         "hogeapp.context_processors.user_name",
         ...,
      )

    $ emacs hogeapp/context_processors.py
      def user_name(request):
         if ( request.user.is_authenticated() ):
            return {"uname": request.user.username}
         else:
            return {"uname": None}

上記の例は、ログインしている場合に、アカウント名を常に「uname」というテンプレート変数に格納するような設定です。