まず、 のrequest.path後のすべて (params を除く)script_rootです。例えば:
のような URL の場合http://127.0.0.1:5000/users/login/、リクエスト データは次のとおりです。
request.path is: /users/login/
上記のリンクの例のような URL の場合http://www.example.com/myapplication/page.html?x=y、リクエスト データは次のとおりです。
request.path is: /page.html
Q. cache_key とはどういう意味ですか? どのように使用できますか?
これcache_keyは、キャッシュされた特定の値にアクセスするために使用されるキーです。ご存じのように、キャッシュはキーと値のストアです。
Flask-Cache では、cache_keyは拡張機能によって生成され、自分で使用することは想定されていません。
Q. key_prefix は何をしますか?
key_prefixcache_keyキャッシュされた値の生成に使用されます。make_cache_keyソースを参照して、それがどのように正確に行われているかを確認してください。
Q. key_prefix を使用する必要はありますか?
get_all_commentsと の2 つの異なるビュー関数から呼び出しているとmanage()しview()ます。key_prefixまた、 でキャッシュget_all_commentsしている間は , を指定しません@cached。
出力を介して投稿を初めて表示すると、次のようなデフォルトのキーがキャッシュされます。viewget_all_commentsview/viewview/module/viewview/%s%srequest.path
次に、 を介して投稿を管理すると、キャッシュからデータを取得するために適用された が に変更され、古い ではないためmanage、get_all_comments出力はキャッシュから読み取られません。これは、 request.path が変更されたためです。cache_keyview/manageview/view
ここでのキャッシングの要点はget_all_comments、データベースではなく可能な限りキャッシュからデータを取得することでしたが、ビュー関数間でキーが変更されたため、データは実際には両方の時点でデータベース自体から取得されます。
ただし、key_prefixlikeを指定した場合all_commentsは、最初にデータベースからデータが取得され、次回cache_keyは静止all_commentsして値が検出され、db ではなくキャッシュからデータにアクセスされます。
したがって、上記のようなケースがある場合は、を使用する方が明らかに良いですがkey_prefix、関数が常に単一のパス/ビュー関数から呼び出される場合は、デフォルトのものを使用しても問題ありません。
注: cache_key はリクエストごとに生成/計算されます。ソースを参照してください:
cache_key = decorated_function.make_cache_key(*args, **kwargs)