Казалось бы, какие проблемы? Кроновские скрипты написаны в контексте зендовского приложения, кеш подключается автоматически - осталось только взять да почистить по тегам методом clean().
Но не тут то было!
Для начала пришлось поправить права для файлового кеша. Поскольку создаётся он сайтом (пользователем вебсервера), а удаляется из под крона (от имени владельца крона).
Соответсвующие опции кеша проставляются примерно так:
resources.cachemanager.NAME.backend.options.hashed_directory_umask = 0777
resources.cachemanager.NAME.backend.options.cache_file_umask = 0777
где NAME - имя вашего кеша.
Вторая трабла случилась непосредственно при попытке удаления записей. Метод clean() возвращает положительный результат и всё как бы хорошо, пока не замечаешь, что кеш то не очищен (Оо).
Благо сорцы копать не привыкать, поэтому вот он, чудесный кусочек метода clean():
class Zend_Cache_Core {
public function clean($mode = 'all', $tags = array())
{
if (!$this->_options['caching']) {
return true;
}
public function clean($mode = 'all', $tags = array())
{
if (!$this->_options['caching']) {
return true;
}
...clean...
}
} Как видите, метод не будет производить чистку, в случае отмены кеширования.}
В моих кроновских скриптах, до очистки кеша, происходит множество действий с моделями, некоторые методы которых могут оказаться закешированы вызовом с клиентской стороны.
Для того, чтобы подстраховаться от сложно-воспроизводимых багов, было решено отменить кеширование для некоторых кешей в случае запуска из консоли (у меня там отдельная секция в application.ini). Это и привело к тому, что кроновские скрипты не могут почистить кеш =(
Мне, признаться, искренне не понятен смысл такой проверки перед очисткой, но решил таки перепроверить все вызовы моделей из крона и включить кеширование обратно (вместо наследования и переопределения).
Комментариев нет:
Отправить комментарий