в ff наблюдаю интересный эффект:
1. Нажимаю на кнопку, в нажатом состоянии увожу курсор
2. Переключаюсь на другую вкладку в браузере
3. Переключаюсь на вкладку обратно и нажимаю на ту же кнопку
Меня не пугает случайная очистка данных, поскольку это лучше чем полная очистка всего кеша, как происходило ранее. В нужный момент подстрахует база данных. В любом случае мемкеш это отдельный сервис и вреда моему здоровью и тем более коду он не принесет. Если всего бояться и не пытаться ходить, тогда и ноги не к чему.
Нет панацеи, кроме увеличения хранилища, до разумных пределов конечно. Распределение нагрузки на несколько серверов. Это экспериментальный путь развития без этого всего прироста не произойдет.
Насчет времени хранения ключей и тегов с одинаковым именем, это конструктивные предложения, по ним будут внесены правки в ближайшее время.
Мой класс не может называться библиотекой, поскольку является расширением, с помощью которого решается не тривиальная задача. И если поддержка тегов мемкеш бекенда это частный случай, то могу смело вам сказать, что ваши заявления ни что иное как попытка попиариться.
Этот частный случай, если вы не заметили есть расширением класса Zend_Cache_Backend_Memcached и реализует работу с тегами. И этот вариант как ни странно рабочий.
1. Ответ не очевиден, поскольку как минимум необходимо знать по какому критерию происходит очистка кеша на стороне сервера, знаю точно, ключи никуда не деваются, чиститься лишь содержимое. Решений может быть несколько: увеличить размер хранилища, разнести кеш на несколько серверов, хранить теги в базе данных, возможно ещё что-нибудь придет в голову.
2. При получении id, это частный случай. В проекте сессия также храниться в мемкеше, но работает на прямую с memcache->get и memcache->set без тегирования, тоесть ключи лежат отдельно. И возникает необходимость очистить весь кеш кроме сессии. Получаю все теги, потом чищу по полученным id.
3. Я описал свой частный случаю, который работает и применим к проекту. Если у вас есть замечания и ответы на них, поделитесь ими.
Предложенное решение разработчики могут использовать на свой страх и риск, впрочем как и весь код предлагаемый на хабре. И он ничем не хуже кода предложенного в самой либе зенда.
Знаю точно, база данных без мемкеша легла бы уже давно.
1. Возможно я не правильно понял вопрос, но у меня нет в этом необходимости.
2. Контейнер тегов нужен для того, чтобы быстро, в случае необходимости получить все id.
3. Пересечение имен тегов на ни в коем образе не навредит, ключи же не пересекаются, поскольку в данном случае произойдет memcache->get. Префикс не нужен, потому что если тег именуется как имя класса и если же он пересекается, то просто идет добавление нового id(key) в хранилище.
За время хранения кэша отвечает параметр 'lifetime', который надо передать в frontendOptions сделать это можно тем же способом как выполнена передача 'non_cached_methods'.
У вас самого нет ощущения явного несовершенства мира
Совершенного мира нет, также как и совершенных систем. Иначе мы бы с вами тут не общались.
$result = $cache->__call($name, $arguments);
Попытаюсь вам объяснить. Класс Zend_Cache_Frontend_Class, который используется в моем примере, устроен так, что для кэширования динамических и статических методов на нужно будет передавать наш объект либо по имени класса 'Default_Models_Products' (для кэширования статики*), либо по ссылке на объект new Default_Models_Products (для кэширования динамики*).
* под статикой и динамикой подразумевается статические и динамические методы
Так вот $cache->__call вызывает магический метод __call того самого класса Zend_Cache_Frontend_Class. А в переменную $cache подставляется либо экземпляр класса созданный для статики, либо экземпляр класса созданный для динамики.
Вот и всё, мой абстрактный класс всего навсего надстройка, созданная для удобства.
1. Нажимаю на кнопку, в нажатом состоянии увожу курсор
2. Переключаюсь на другую вкладку в браузере
3. Переключаюсь на вкладку обратно и нажимаю на ту же кнопку
в .ds-button не хватает стиля outline: none;
Нет панацеи, кроме увеличения хранилища, до разумных пределов конечно. Распределение нагрузки на несколько серверов. Это экспериментальный путь развития без этого всего прироста не произойдет.
Насчет времени хранения ключей и тегов с одинаковым именем, это конструктивные предложения, по ним будут внесены правки в ближайшее время.
fixed
все остальное просто слова
2. При получении id, это частный случай. В проекте сессия также храниться в мемкеше, но работает на прямую с memcache->get и memcache->set без тегирования, тоесть ключи лежат отдельно. И возникает необходимость очистить весь кеш кроме сессии. Получаю все теги, потом чищу по полученным id.
3. Я описал свой частный случаю, который работает и применим к проекту. Если у вас есть замечания и ответы на них, поделитесь ими.
Предложенное решение разработчики могут использовать на свой страх и риск, впрочем как и весь код предлагаемый на хабре. И он ничем не хуже кода предложенного в самой либе зенда.
Знаю точно, база данных без мемкеша легла бы уже давно.
2. Контейнер тегов нужен для того, чтобы быстро, в случае необходимости получить все id.
3. Пересечение имен тегов на ни в коем образе не навредит, ключи же не пересекаются, поскольку в данном случае произойдет memcache->get. Префикс не нужен, потому что если тег именуется как имя класса и если же он пересекается, то просто идет добавление нового id(key) в хранилище.
4. Выходит так, но мы этого делать не будем :)
5. Спасибо, критичное замечание.
онлайн 800+
Совершенного мира нет, также как и совершенных систем. Иначе мы бы с вами тут не общались.
Попытаюсь вам объяснить. Класс Zend_Cache_Frontend_Class, который используется в моем примере, устроен так, что для кэширования динамических и статических методов на нужно будет передавать наш объект либо по имени класса 'Default_Models_Products' (для кэширования статики*), либо по ссылке на объект new Default_Models_Products (для кэширования динамики*).
* под статикой и динамикой подразумевается статические и динамические методы
Так вот $cache->__call вызывает магический метод __call того самого класса Zend_Cache_Frontend_Class. А в переменную $cache подставляется либо экземпляр класса созданный для статики, либо экземпляр класса созданный для динамики.
Вот и всё, мой абстрактный класс всего навсего надстройка, созданная для удобства.