Комментарии 31
Эмм… Скажите, а почему не расширить стандартный Cache_File до Cache_Filetag по аналогии с Cache_Memcachetag? Изменений будет немного, заново придумывать (или выдергивать из стандартного Cache_File) основные методы не надо. Если уж на то пошло, файловый кэш с тэгами существовал в версии 2.3.4, так что выдернуть оттуда его несложно.
Еще дополню.
1. Зря Вы храните все файлы кэша в одной директории. В оригинальном модуле кэш сохраняется в поддиректории, имена которых берутся их хэша имени файла (т.е. что-то типа cache/ab/cd/abcdef.txt).
2. Ну и поиск по тэгам у Вас неуклюжий получается. Надо считать строку из файла. Опять же, в 2.3.4 тэги хранятся прямо в имени файла, что облегчает их поиск (там через glob() все сделано).
1. Зря Вы храните все файлы кэша в одной директории. В оригинальном модуле кэш сохраняется в поддиректории, имена которых берутся их хэша имени файла (т.е. что-то типа cache/ab/cd/abcdef.txt).
2. Ну и поиск по тэгам у Вас неуклюжий получается. Надо считать строку из файла. Опять же, в 2.3.4 тэги хранятся прямо в имени файла, что облегчает их поиск (там через glob() все сделано).
Сказать честно, я пользуюсь Kohana с версии 3.0, поэтому файловый кэш с тегами не застал. Нужно будет изучить эту реализацию. Остальные замечания всенепременнейше учту в JetCache 2.0 )
Гм… Если Вы начнете с моего первого замечания, то JetCache v2 просто не будет :) Напишите Cache_Filetag и предложите его сообществу. Это и будет Kohana way.
Ну или так )
Правда, у них уже есть готовое решение. Интересно, почему оно не вошло в 3 версию.
Правда, у них уже есть готовое решение. Интересно, почему оно не вошло в 3 версию.
Вероятно из-за тормознутости файлового кэша. Хотите более удобной и быстрой работы кэша — используйте, к примеру. Memcache/Memcachetag
Может быть. Но в условиях сайтов с невысокой посещаемостью, размещенных на стандартных хостингах, такие варианты не применимы из-за отсутствия Memcache и других замечательных вещей. Остаются только файлы.
А ещё есть sqlite-кеш. Он тоже поддерживает теги
Как было сказано в постановке задачи, в данном случае подходят только файлы )
К тому же, я придерживаюсь мнения, что если есть возможность использовать использовать софт из дополнительного набора, лучше использовать Memcache или Xcache. Например, в документации скорость работы Sqlite оценена как «Poor» — так же, как и у файлового кэша: kohanaframework.org/3.1/guide/cache#choosing-a-cache-provider
К тому же, я придерживаюсь мнения, что если есть возможность использовать использовать софт из дополнительного набора, лучше использовать Memcache или Xcache. Например, в документации скорость работы Sqlite оценена как «Poor» — так же, как и у файлового кэша: kohanaframework.org/3.1/guide/cache#choosing-a-cache-provider
Дык poor в случае с файлами — это еще без тэгов :) С тэгами он может стать ugly
А sqlite — это не файл? Или на хостинге нет поддержки PDO?
Делал похожий механизм для ZF, сейчас переношу его на проект, написанный на Kohana 3.1, но с небольшими дополнениями — есть такая задумка определять теги автоматически, разобрав sql-запрос и выбрав из него все используемые таблицы, используя их как теги при модификации (для сброса) и выборке (для сохранения). Решение довольно деревянное, но для сайтов с не слишком хитрой структурой кэша подойдет прекрасно.
Ох, господи, вот люди верхов нахватаются и полезут «кеширование» делать, еще и на файлах (а, еще есть оригиналы из Друпала, они вообще где-то в базе данные кешируют). Объясните, какой смысл тормозным скриптом лазать по иерархической файловой системе, открывать каждый файл и перечитывать теги (это же быдлокод), когда можно просто добавить ключики, вроде filebank_files_update_time и что там у вас еще есть, и при чтении из кеша проверять дату обновления этих ключей, если запись в кеше зависит от них, и она старше — знаичт, она устарела.
У вас когда будут тысячи файлов в этом недокеше, вы тоже каждый открывать будете?
У вас когда будут тысячи файлов в этом недокеше, вы тоже каждый открывать будете?
Почти на все вопросы ответ содержится в постановке задачи )
На файлах потому, что нет другого выхода — ограничения хостинга. Записывать все данные в имена файлов было бы можно, но для конкретной задачи, как мне кажется, не обязательно. К тому же, скорость чтения файла будет выше, если обратиться к нему по полному имени, а не по маске.
Как я уже говорил, предполагается использование на небольших сайтах, администрируемых одним человеком или небольшой группой людей. Информация обновляется нечасто, а ведь именно при обновлении происходит чтение всех файлов.
Таким образом, СУБД разгружена, у клиентов скорость чтения увеличена. А администратор может потерпеть ) Тысяч файлов, опять же, не будет из-за относительно небольшого объема информации.
А для сайтов, где огромная база данных, частое обновление информации и все такое, нужен серьезный хостинг. И для этого случая во фреймворке уже есть хорошие стандартные решения, и ничего изобретать не надо.
На файлах потому, что нет другого выхода — ограничения хостинга. Записывать все данные в имена файлов было бы можно, но для конкретной задачи, как мне кажется, не обязательно. К тому же, скорость чтения файла будет выше, если обратиться к нему по полному имени, а не по маске.
Как я уже говорил, предполагается использование на небольших сайтах, администрируемых одним человеком или небольшой группой людей. Информация обновляется нечасто, а ведь именно при обновлении происходит чтение всех файлов.
Таким образом, СУБД разгружена, у клиентов скорость чтения увеличена. А администратор может потерпеть ) Тысяч файлов, опять же, не будет из-за относительно небольшого объема информации.
А для сайтов, где огромная база данных, частое обновление информации и все такое, нужен серьезный хостинг. И для этого случая во фреймворке уже есть хорошие стандартные решения, и ничего изобретать не надо.
Ох, боюсь мы с вами не поняли друг друга. Главная моя претензия не к хранению кеша в файлах, а к использованию дурной, уродливой, придуманной видимо индусами системы тегов в кеше, зачем они нужны, когда можно сделать проще?
Об этом я и писал выше. В оригинальной библиотеке Cache v2.3.4 имена файлов были вида id~tag1+tag2+tag3~lifetime, и для обработки тэгов и lifetime достаточно обработать имя файле, не заглядывая внутрь.
С одной стороны, это решение действительно привело бы к оптимизации поиска по тегам. Но нужна ли она в тех условиях, которые я описал? Ведь это привело бы к увеличению времени поиска по ключу, что здесь более критично, так как поиск по ключу — для клиентов, поиск по тегам — для администратора.
Почему это для администраторов? По идее, тэги должны использоваться самой системой для своевременного удаления кэша при наступлении соответствующего события. Например, добавилась статья в категорию N — и кэш с тэгом categoryN должен быть очищен. Не администратор же вручную должен этим управлять.
Так здесь статьи добавляются только администратором ) Такое решение было выбрано с учетом этой особенности, я это указывал.
Комментарии, фотографии и т.д.
В любом случае, Вы предлагаете сообществу модуль, но при этом изначально его сильно ограничиваете. Какой смысл?
В любом случае, Вы предлагаете сообществу модуль, но при этом изначально его сильно ограничиваете. Какой смысл?
Да, здесь не предполагается добавление информации пользователями, ограничение существенное. Но в сфере сайтов, например, для небольших фирм, это не требуется. Модуль разрабатывался именно для подобных случаев. В других условиях, конечно, нужно было бы применять более оптимальные методы, а еще лучше — Memcache и другие хорошие вещи.
А Вы читали о стиле оформления кода и соглашениях об именовании в Kohana?
Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.
Многие вещи в соглашении Коханы расходятся с моими моральными принципами. Например, для того, чтобы написать так:
мне нужно фактически переступить через себя ) Я привык писать «неправильно»:
Все-таки, в случае, если код не будет включаться в какой-то общий проект, тонкости оформления кода, такие как, где ставить скобки или пробелы — это вопрос вкуса. К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
Многие вещи в соглашении Коханы расходятся с моими моральными принципами. Например, для того, чтобы написать так:
// Correct:
$db = new Database;
мне нужно фактически переступить через себя ) Я привык писать «неправильно»:
// Incorrect:
$db = new Database();
Все-таки, в случае, если код не будет включаться в какой-то общий проект, тонкости оформления кода, такие как, где ставить скобки или пробелы — это вопрос вкуса. К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
Ну Вы хотя бы соблюдайте один и тот же стиль :) А то protected-методы с подчеркивания начинаются, а свойства — нет. То у Вас CamelCase-методы, то опять с подчеркиваниями. Как будто писали разные люди.
Свойства я обычно не делаю публичными, поэтому не выделяю их. Я разделяю мнение, что прямого доступа к свойствам следует избегать.
Методы бывают как публичные, так и защищенные, поэтому защищенные я выделяю подчеркиванием в начале, чтобы при чтении кода было понятно, что вызывается защищенный метод, вызов которого извне не предусмотрен.
В основном я использую CamelCase. Здесь через подчеркивание назвал аналоги методов из класса Cache_File.
Методы бывают как публичные, так и защищенные, поэтому защищенные я выделяю подчеркиванием в начале, чтобы при чтении кода было понятно, что вызывается защищенный метод, вызов которого извне не предусмотрен.
В основном я использую CamelCase. Здесь через подчеркивание назвал аналоги методов из класса Cache_File.
Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.
Тут нужно или трусы надеть, или крестик снять.
Если 'в Kohana' — то можно было расширить (или заново реализовать), файловый кеш который уже существует, прикрутив к нему теги (как справедливо предложил dohlik), до кучи переступив через себя и приведя код в соответствие с принятыми в сообществе стандартами.
Если нет — слово Kohana скорее лишнее. Тем более, что в предлагаемом классе используется разве что конфиг, который из зависимостей при большом желании выпиливается ну просто на раз-два.
Небольшая ремарка. Сами кохановцы делают зависимость от конфига ещё более слабой, обратите внимание. Обращение к классу Config (или прокси Kohana::config) используется в основном только во вспомогательных статических методах, которые передают уже полученный конфиг в виде массива в конструктор.
К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
Не настроенное под конкретную ситуацию автоформатирование.
Не надо сваливать на настройки IDE, поставляемые с ней по умолчанию.
Я не ищу оправданий в стандартном стиле IDE, я привел его как пример зависимости тонкостей стиля написания кода от вкусов человека, пишущего код.
Наверно, конечно, вы правы в том, что при публикации материалов о фреймворке приведение кода к его стандартам является плюсом. Но разве при разработке под каждый фреймворк обязательно нужно соблюдать индивидуальный стиль кода его дистрибутива? Например, у Zend framework'а другие стандарты, а переключаться в голове между разными стилями не так просто )
Наверно, конечно, вы правы в том, что при публикации материалов о фреймворке приведение кода к его стандартам является плюсом. Но разве при разработке под каждый фреймворк обязательно нужно соблюдать индивидуальный стиль кода его дистрибутива? Например, у Zend framework'а другие стандарты, а переключаться в голове между разными стилями не так просто )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Первичный кэш в Kohana 3 с использованием тегов