Сегодня какое-то время думал над этим вопросом. В новом примере/сравнении(папка compare), кстати, это займёт кучу времени. Выходит +1 запрос на каждую переменую, получается минимум двухкратное увеличение количества запросов. Что в итоге выливается в худшее быстродействие, чем штатный Zend_Cache. А нужно как-раз наоборот. Хотя, это сферический пример в вакууме — 100 добавлений и удалений разных переменных.
Нужно будет по-играться с более приближенными к реальности данными и их количеством, может оно того и стоит в меньших масштабах. Добавлю это как опцию в крайнем случае.
Мне не нравится ZF. Это принципиально.
Помимо этого я хочу проще.
Вот, к примеру, я не смог за 10 минут запустить ZC, просто чтоб сравнить их быстродействие. Подозреваю, что решение от Zend будет немного медленнее. Не разобрался. Я на работе и не могу на это тратить много времени. Сравню из дому. Но, думаю, это уже дополнительный минус ZC от меня лично.
1) Возможно овтечу, если вы ответите на четывёртый пункт.
2) Многоуровневый кеш не реализован.
3) Либо добавить вызовы Memcache::AddServer() в конструкторе бэкенда Memcache самому и сейчас, либо дождаться следующего релиза.
4) Если вы про debug_backtrace(), то это не решение. Если знаете лучший способ, поделитесь.
Нет крутых паттернов, есть подходящий инструмент для поставленной задачи. Задача была поставлена как полная инкапсуляция — отсутствие переменных и минимальное присутствие в чужом коде.
Тем что моя реализация универсальна и не привязана ни к memcache ни к ZF.
Синглтон — создатся всего один объект, он спрятан внутри класса и никак не мешается в чужом коде. Автодополнение работает на ура. В этом была суть — в возможности безболезненной интеграции в чужой код без его изменения. Имеется в виду добавление логики (if/else/...), можно уложиться в 3 строчки на один элемент кеша.
Я просто выбрал неудачное имя параметра — PAR_ID будет достаточно, его можно использовать в любых других местах, где есть какие-либо айдишники. Параметры не несут смысловой нагрузки и служат для различения контента, вышедшего из одной функции с одними и теми же параметрами.
Ещё раз: Если из одной функции/метода выходят разные данные, значит они зависят от каких-то внешних параметров. И значит их нельзя кешировать под одним именем. По этому мы добавляем кешевый «параметр»
а можно и несколько, если надо. Эти параметры добавляются к имени переменной в кеше, внутри системы. Т.о. для каждых данных у нас разные имена.
Что имеется в виду под пересечением тегов? Несколько тегов соответствуют одной переменной? Если у вас появляется необходимость использовать несколько тегов для одной переменной, можно указать их через запятую. Пример сходу придумать не могу. Но суть-то в том чтоб при удалении тега удалять все кешевые переменные, с ним ассоциированные. Пересекающиеся теги это частный случай. Если засунуть одну и ту же переменную под два разных тега, она не станет двумя разными переменными.
Единственная проблема, которю я предвижу, это, скажем, удаление всех закешированных статей, при удалении по тегу TAG_ARTICLE, если, к примеру, произошло редактирование всего какой-то одной. Что бы этого избежать я добавлю поддержку кешевых параметров для удаления по тегу. Скоро.
Дело в том, что для этого существуют парамерты, они позволяют разделить кеш, полученный из одной и той же функции с одними и теми же параметрами.
Что касается поводу удаления… Да, я думал над добавлением поддержки параментров PAR_* для удаления кеша, не только для добавления. В примере со статьями тег был бы TAG_ARTICLES а парамерт PAR_ARTICLEID c нужным айди. Если вдруг поднадобится удалить кеш этой конкретной статьи и ничего другого с тегом PAR_ARTICLES, нужно будет указать парамерт PAR_ARTICLEID перед удалением тега TAG_ARTICLES. Так пойдёт?
Объект инстаницируется внутри класса, когда это необходимо. Если вы взглянете на код, вы увидите. Отсутствие new было задумано чтоб минимизировать свой код в чужом.
По-видимому, коментатор хотел обратить внимание на частый выход новых топиков Яндекса на Хабре. Усреднённо по два топика за 3 дня, если брать в расчёт только текущий месяц. И то, что если раньше не обязательно было читать корпортавиный блог Яндекса, то сейчас приходится хотя бы пробежаться глазами — его зеркало теперь в выдаче Хабра.
Почему же не делаются. Очень даже. Причём в первую очередь. Если поискать в интернете, можно найти десятки сайтов афиш Одессы со всяческими рассылками. Есть среди них вполне достойные. Что же касается афиши Одессы, как приложения для айфона, то оно появилось впервые.
В каждом универе она должна быть. Если нет — наиболее преприимчивые организовывают. Выгодно это. Другое дело, что в универах, порой, столовки «столовками» называть даже язык не поворачивается. Вот у нас, к примеру, вместо столовки был Бар «Волосатая плацинда». Волшебное место.
Не особо тёмные иконки, с Foreground color равным, к примеру, светлому #BBBBBB не различимы на белом фоне. Пример со стрелочками. Цвет ещё светлее делают иконку полностью белой. А вот облачку и #888888 хватило.
Нужно будет по-играться с более приближенными к реальности данными и их количеством, может оно того и стоит в меньших масштабах. Добавлю это как опцию в крайнем случае.
Помимо этого я хочу проще.
Вот, к примеру, я не смог за 10 минут запустить ZC, просто чтоб сравнить их быстродействие. Подозреваю, что решение от Zend будет немного медленнее. Не разобрался. Я на работе и не могу на это тратить много времени. Сравню из дому. Но, думаю, это уже дополнительный минус ZC от меня лично.
1) Возможно овтечу, если вы ответите на четывёртый пункт.
2) Многоуровневый кеш не реализован.
3) Либо добавить вызовы Memcache::AddServer() в конструкторе бэкенда Memcache самому и сейчас, либо дождаться следующего релиза.
4) Если вы про debug_backtrace(), то это не решение. Если знаете лучший способ, поделитесь.
Нет крутых паттернов, есть подходящий инструмент для поставленной задачи. Задача была поставлена как полная инкапсуляция — отсутствие переменных и минимальное присутствие в чужом коде.
Но реализация с заморозкой скрипта на целую секунду сомнительна.
Нужно обдумать.
Синглтон — создатся всего один объект, он спрятан внутри класса и никак не мешается в чужом коде. Автодополнение работает на ура. В этом была суть — в возможности безболезненной интеграции в чужой код без его изменения. Имеется в виду добавление логики (if/else/...), можно уложиться в 3 строчки на один элемент кеша.
Ещё раз: Если из одной функции/метода выходят разные данные, значит они зависят от каких-то внешних параметров. И значит их нельзя кешировать под одним именем. По этому мы добавляем кешевый «параметр»
MemcacheTag::SetParam(MemcacheTag::PARAM_ID, $currentArticleId);
а можно и несколько, если надо. Эти параметры добавляются к имени переменной в кеше, внутри системы. Т.о. для каждых данных у нас разные имена.
Что имеется в виду под пересечением тегов? Несколько тегов соответствуют одной переменной? Если у вас появляется необходимость использовать несколько тегов для одной переменной, можно указать их через запятую. Пример сходу придумать не могу. Но суть-то в том чтоб при удалении тега удалять все кешевые переменные, с ним ассоциированные. Пересекающиеся теги это частный случай. Если засунуть одну и ту же переменную под два разных тега, она не станет двумя разными переменными.
Единственная проблема, которю я предвижу, это, скажем, удаление всех закешированных статей, при удалении по тегу TAG_ARTICLE, если, к примеру, произошло редактирование всего какой-то одной. Что бы этого избежать я добавлю поддержку кешевых параметров для удаления по тегу. Скоро.
Что касается поводу удаления… Да, я думал над добавлением поддержки параментров PAR_* для удаления кеша, не только для добавления. В примере со статьями тег был бы TAG_ARTICLES а парамерт PAR_ARTICLEID c нужным айди. Если вдруг поднадобится удалить кеш этой конкретной статьи и ничего другого с тегом PAR_ARTICLES, нужно будет указать парамерт PAR_ARTICLEID перед удалением тега TAG_ARTICLES. Так пойдёт?