modx cacheManager: где "хранится" время жизни ?

$value = '555';
$modx->cacheManager->set('test', $value, 20);
echo $modx->cacheManager->get('test');

Здесь кэш должен «храниться» 20 сек. Фактически этот код возвращает '555' и через час, и через два.
Физически, в /core/cache/default лежит файл test.cache.php. А где «лежит» его время жизни ?

Cyrax_02

25 августа 2014, 16:05

4 480

-1

Комментарии: 19

Василий Наумкин

25 августа 2014, 22:38

Время жизни лежит в самом файле кэша:

<?php if(time() > 1408985878){return null;} return array (
// ... Сохранённые данные
);

Cyrax_02

25 августа 2014, 23:07

У меня modx глючит.
В шаблоне tpl_test указываю:

[[!snp_test]]

У ресурса test в качестве шаблона указываю tpl_test.
Загружаю этот ресурс — в /core/cache/includes/elements/modsnippet появляется кэш сниппета. Удаляю этот кэш-файл, загружаю ресурс — кэш-файл сниппета снова появляется.

Шаблон ресурсу прописываю верный. Если в шаблоне отключить сниппет

[[-!snp_test]]

то при загрузке ресурса получаем пустой экран. При этом в /core/cache/includes/elements/modsnippet никаких файлов кэша не появляется.

Бред какой-то. Сниппет вызываю НЕкэшируемым. А он всё равно кэшируется. При загрузке ресурса отрабатывает сниппет из кэша. Галку «Очистить кэш при сохранении» снял и у шаблона, и у сниппета.

Василий Наумкин

25 августа 2014, 23:13

1. При сохранении шаблона кэш сайта очищается.
2. При загрузке страницы с отключенным сниппетом — он не выполняется и кэша для него нет.

Что не так?

Cyrax_02

25 августа 2014, 23:17

При сохранении шаблона кэш сайта не очищается, потому что галку «Очистить кэш при сохранении» у шаблона я отключил.
У ресурса галку «кэшируемый» снял.
У сниппета галку «Очистить кэш при сохранении снял».

При этом наблюдаю артефакт: некэшируемый сниппет кэшируется.
Т.е. если кэш сайта не очищать, то при загрузке ресурса появляется кэш сниппета. А если измененить код сниппета и сохранить его, то при загрузке ресурса выполняется код из кэша.

Василий Наумкин

25 августа 2014, 23:21

Ты хоть в код этого файла посмотри. Видишь там отметку времени, или массив данных, похожий на кэш?

Нет, там лежит сам код сниппета, который и выполняется. Или ты считаешь, что нужно через eval() запускать всё из БД, без сохранения в файл?

Revolution не использует eval(), и правильно делает.

Cyrax_02

25 августа 2014, 23:25

Я не против хранения кода сниппета.
Но какого хрена там хранится старый код? И этот старый код всё время выполняется.
Вот я изменил код сниппета, сохранил его. Вместо '555' он должен возращать '666'. Запускаю ресурс — получаю '555'. Это нормально? При том, что кэширование отключено.

Василий Наумкин

26 августа 2014, 07:27

Нет, это ненормально.

Как обычно, у тебя глючит MODX. Везёт тебе.

Cyrax_02

26 августа 2014, 11:22

Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.

Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).

А почему никто, кроме меня, на этот артефакт внимания не обращал — потому что у всех стоит галка «Очистить кэш при сохранении» (при сохранении кэш очищается => при вызове сниппета выполняется актуальный в данный момент код сниппета).

Василий Наумкин

26 августа 2014, 11:28

То есть, ты не очищаешь кэш, и удивляешься, что он не очищается?

Действительно, прикол от разработчиков.

Cyrax_02

26 августа 2014, 11:51

Т.е. вы признаёте, что это кэш сниппета?
Я удивляюсь, что «он» не обновляется (очищаться он и не должен, т.к. галка очистки снята) при изменении сниппета. И не на пустом месте.

В modx мы имеем место с 2 логическими категориями:
1) Кэширование элемента или ресурса. В случае с элементами — это восклицательный знак перед именем элемента. В случае с ресурсом — галка «Кэшируемый». Логика этой категории такова, что что запрет кэширования означает, что ВСЕГДА обрабатываются актуальные на текущий момент данные и выполняется актуальный на текущий момент код.

2) Очистка кэша при сохранении. Означает, что если мы изменяем элемент или ресурс, то при последующей загрузке страницы мы получим актуальные данные и актуальный код.

Но в случае со сниппетом запрет кэширования НЕ означает выполнение актуального кода (нарушена логика #1). Всё встало бы на свои места, если бы при запрете кэширования сниппета и при отключенной галке «Очистить кэш при сохранении» этот самый файл обновлялся (актуализировался). Только в этом случае вышеизложенная логика полностью бы соблюдалась.

Т.е. при запрете кэширования сниппета всегда должен выполняться актуальный на текущий момент код, независимо от того, каким образом физически реализована работа с этим сниппетом. Если бы код сниппета извлекался бы из БД, то проблемы бы не было. Ну а коли код сниппета сохраняется в файле, то этот файл должен поддерживаться в актуальном состоянии (если кэширование запрещено).

Алексей Ерохин

26 августа 2014, 14:29

В папке core/cache/includes хранится обернутый в функции код сниппетов, плагинов. Сделано для более быстрого вызова. Это не кэш. Кэш сниппетов и плагинов хранится в папке core/cache/scripts. Когда Вы вызываете кешированный сниппет, он берется из core/cache/scripts. Когда Вы вызываете некешированный сниппет он берется из core/cache/includes, если существует, иначе генерируется новый.

Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.

Алексей Ерохин

26 августа 2014, 14:30

Вообщем, все работает так как предусмотрено разработчиками. Никаких глюков не наблюдается. Недоумевалки и хотелки пишите разработчикам modx.

Cyrax_02

26 августа 2014, 16:36

Не очистив кеш при изменении сниппета, Вы оставили старым xx.include.cache.php.

Как Вы сами же говорите, xx.include.cache.php — НЕ кэш сниппета. Тогда почему этим файлом должна управлять галка «Очистить кэш»?

Согласен, что xx.include.cache.php — не кэш сниппета (если говорить о кэшировании значения, возвращаемого сниппетом). xx.include.cache.php — это фактически зеркало того кода, который хранится в БД. Т.е. код сниппета хранится в 2 местах — в стандартной БД и в файле. Имеет место оправданная избыточность данных.

Но почему Вы считаете, что это самое зеркало и код в БД не должны друг другу соответствовать? И речь не идёт о кэше. Если одни и те же данные в некоторый момент времени оказываются разными, имеет место нарушение целостности, что мы и наблюдаем при изменении кода сниппета в БД.

Вы считаете нарушение целостности данных нормальным?

Алексей Ерохин

26 августа 2014, 17:03

Потому что очистка кеша — очистка папки core/cache, где все это находится.

В базе код сниппета. В файле — код для инклюда (функция). Никакого зеркалирования тут нет. Код из базы берется 1 раз при первом вызове сниппета (если нет кеша). В остальное время есть кеш и/или готовая к инклюду функция. Если Вы сознательно не обновляете эти данные, как Вы хотите получить свежую информацию?

Специально, чтобы не было нарушения целостности и стоит галочка «Обновлять кеш при сохранении».

Предвосхищая вопросы «Зачем это нужно»
Например, сниппет будет возвращать другое значение (не true|false, а количество элементов). А чанки с вызовом сниппета я не могу менять (прав нет), этим занят фронтенд-разработчик. А я изменил код сниппета. Завтра второй разработчик доделает чанки и обновит кеш, и все будет хорошо.

Cyrax_02

26 августа 2014, 18:46

Есть текущие (актуальные) данные и закэшированные данные. Третьего не дано. Если мы работаем с кэшируемыми данными (кэшируемые ресурсы, кэшируемые элементы), то при загрузке веб-страниц отображаются закэшированные данные. Если мы работает с НЕкэшируемыми данными, то при загрузке веб-страниц должны отображаться всегда актуальные данные.

В остальное время есть кеш и/или готовая к инклюду функция.

Отделяем мух от котлет:
Если по замыслу разработчиков include-код имеет отношение к кэшу элемента (т.е. является кэшем include-кода), то этот кэш include-кода вообще НЕ должен использоваться при вызове НЕкэшируемого элемента.
Если же по замыслу разработчиков include-код является include-вариантом текущего кода элемента, то он всегда должен поддерживаться в актуальном состоянии (т.е. обновляться при обновлении исходного кода элемента).

Сейчас же мы наблюдаем смешанную логику:
В ходе обработки НЕкэшируемого элемента парсером modx этот файл выступает в качестве include-варианта текущего кода элемента. А при изменении исходного кода сниппета — в качестве кэша include-кода.
Такого быть не должно. Логика должна быть однозначной — либо это кэш-side, либо не кэш-side.

Предвосхищая вопросы «Зачем это нужно»
Например, сниппет будет возвращать другое значение (не true|false, а количество элементов). А чанки с вызовом сниппета я не могу менять (прав нет), этим занят фронтенд-разработчик. А я изменил код сниппета. Завтра второй разработчик доделает чанки и обновит кеш, и все будет хорошо.

Ну ведь очевидно, что разработчики modx реализовали именно такой вариант работы парсера (не eval'ом из БД, а include'ом из внешнего файла) не для того, чтобы синхронизировать раздельную работу разработчиков.
Ваш пример всего лишь показывает, как с пользой можно использовать эту «особенность» modx.

Специально, чтобы не было нарушения целостности и стоит галочка «Обновлять кеш при сохранении».

Всё-таки цель этой галки несколько иная. Не обеспечение целостности данных (целостность данных должна обеспечиваться всегда, везде и в безусловном порядке, а если нужны варианты данных на разные моменты времени, здесь уже вводим категории снимков данных, кэша, версий и пр.), а актуализация кэша (в силу реализации новые кэш-данные физически будут созданы при первом вызове, но смысл именно такой).

Володя

26 августа 2014, 07:36

ну у тебя какой нибудь оптимизатор php на серваке наверно, вот и все…

Cyrax_02

26 августа 2014, 11:17

Нет никакого оптимизатора.
Я же слежу непосредственно за файлом 200.include.cache.php (сниппет snp_test имеет id 200) в директории /core/cache/includes/elements/modsnippet. А этим файлом и в этой директории управляет исключительно modx. Этот файл после первого создания никогда не меняется. Если только очистить кэш, он пересоздастся.

Cyrax_02

26 августа 2014, 11:27

Ещё один артефакт. Вернее, как уже выяснилось, так было задумано разработчиками.
Галка «Очистить кэш при сохранении» у элементов (сниппеты, плагины, чанки, шаблоны) и галка «Очистить кэш» у ресурсов НЕ имеют собственного поля в БД.

Как следствие:
а) при снятии этой галки и сохранении элемента/ресурса состояние галки в БД запомнено не будет
б) при загрузке (перезагрузке) страницы элемента/ресурса эта галка ВСЕГДА устанавливаются

Это вторая причина, по которой никто не замечал вот этого артефакта:

Нет. Это прокол разработчиков modx.
По их замыслу, файл xx.include.cache.php сниппета должен создаваться всегда. В зависимости от запрета кэширования этот файл возвращает либо значение сниппета (полученное при первом выполнении кода сниппета), либо его код.

Только вот позабыли разработчики обновлять этот файл при сохранении сниппета (при отключенной галке «Очистить кэш при сохранении»).

Василий Наумкин

26 августа 2014, 11:32

Гражданин Cyrax_02, у тебя все вопросы такие.

Ты каждый раз находишь тотальные недостатки, которые никто не замечает. И каждый раз выносишь мозг сверлением «а почему так?». То, что обычные люди делают за 2 клика без заморочек, ты декомпилируешь до уровня php модулей.

Честное слово, я больше просто не буду тебе ничего отвечать, надоело. Зануда 60 lvl.

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.