Лишение законной силы пути от кэша Django рекурсивно
Я удаляю единственный путь из кэша Django как это:
from models import Graph
from django.http import HttpRequest
from django.utils.cache import get_cache_key
from django.db.models.signals import post_save
from django.core.cache import cache
def expire_page(path):
request = HttpRequest()
request.path = path
key = get_cache_key(request)
if cache.has_key(key):
cache.delete(key)
def invalidate_cache(sender, instance, **kwargs):
expire_page(instance.get_absolute_url())
post_save.connect(invalidate_cache, sender = Graph)
Это работает - но является там способом удалить рекурсивно? Мои пути похожи на это:
/graph/123 /graph/123/2009-08-01/2009-10-21
Каждый раз, когда график с идентификатором "123" сохраняется, кэш для обоих путей должен делаться недействительным. Это может быть сделано?
2 ответа
Возможно, вы захотите посмотреть на использование стратегии кэширования генерации, похоже, что она будет соответствовать тому, что вы пытаетесь выполнить. В указанном вами коде вы бы хранили номер «поколения» для каждого абсолютного URL-адреса. Таким образом, например, вы будете инициализировать «/ график / 123», чтобы иметь поколений одного, то его ключ кэша станет чем-то вроде «/ поколения / 1 / график / 123». Когда вы хотите истечь кэш для этого абсолютного URL URL, вы увеличиваете значение его генерации (до двух в этом случае). Таким образом, в следующий раз, когда кто-то идет, чтобы посмотреть «/ график / 123» ключ кэша становится «/ поколением / 2 / график / 123». Это также решает проблему срок действия всех подпунктивных страниц, поскольку они должны ссылаться на тот же ключ кэширования, что и «/ график / 123».
Это немного сложно понять сначала, но это действительно элегантная стратегия кэширования, которая, если она сделана правильно означает, что вам никогда не придется удалять что-либо из кэша. Для получения дополнительной информации здесь находится презентация по генерационному кэшированию , ее для рельсов, но концепция такая же, независимо от языка.
проверка shutils.rmtree() или os.removeirs(). Я думаю, что первое, вероятно, то, чего вы хотите.
Обновление, основанное на нескольких комментариях: На самом деле, механизм кэширования Django более общий и тонкий, чем просто использование пути для ключа (хотя вы можете использовать его на этом уровне). У нас есть несколько страниц, которые имеют 7 или 8 отдельно кэшированных подкомпонентов, срок действия которых истекает по ряду критериев. Имена кэш-памяти наших компонентов отражают ключевые объекты (или классы объектов) и используются для определения того, что должно быть недействительным при определенных обновлениях.
Все наши страницы имеют общий кэш-ключ, основанный на статусе "член/не-член", но это только около 95% страницы. Остальные 5% могут изменяться в зависимости от статуса участника и поэтому вообще не кэшируются.
Как вы выполняете итерацию через кэш, чтобы найти недействительные элементы, зависит от того, как они на самом деле хранятся. Если это файлы, то вы можете использовать просто глобы и/или рекурсивные удаления каталогов, если это какой-то другой механизм, то вам придется использовать что-то другое.
Мой ответ, и некоторые комментарии других, пытаются сказать, что то, как вы выполняете проверку недействительности кэша, тесно связано с тем, как вы используете/храните кэш.
Второе обновление : @andybak: Значит, ваш комментарий означает, что все мои коммерческие сайты Django взорвутся в огне? Спасибо, что предупредили об этом. Я заметил, что вы не пытались ответить на эту проблему.
Проблема снапа в том, что у него есть группа кэшированных элементов, которые кажутся родственными и находятся в иерархии из-за их названий, но логика генерации ключей механизма кэширования стирает это название, создавая MD5-хэш пути + vary_on. Так как нет следов оригинального пути/пар, вам придется исчерпывающе угадывать все возможные комбинации путь/пар, в надежде, что вы сможете найти нужную группу. У меня есть и другие увлечения, более интересные.
Если вы хотите иметь возможность найти группы кэшированных элементов на основе некоторой комбинации путей и/или значений параметров, вы должны либо использовать ключи кэширования, которые могут быть непосредственно сопоставлены по шаблону , либо какую-нибудь систему, которая сохраняет эту информацию для использования во время поиска.
Поскольку у нас не было потребностей, не связанных с проблемой операционной системы, мы взяли под контроль кэширование фрагментов шаблонов, а именно генерацию ключей, более 2 лет назад. Это позволяет нам использовать регеxps несколькими способами для эффективной проверки недействительности групп связанных кэшированных элементов. Мы также добавили таймаут по умолчанию и варьирование имен переменных (разрешаемых во время выполнения), настраиваемых в settings.py, изменили порядок следования имен и таймаутов, потому что не было смысла всегда переопределять таймаут по умолчанию для того, чтобы назвать фрагмент, сделали имя_фрагмента разрешаемым (т.е. это может быть переменная), чтобы лучше работать с многоуровневой схемой наследования шаблона, и еще кое-что.
Единственная причина моего первоначального ответа, который действительно был неправильным для нынешнего Django, заключалась в том, что я так долго пользовался ключами кэширования saner, что буквально забыл о простом механизме, от которого мы ушли.