Search
Write a publication
Pull to refresh
55
0
Иван Шумков @Shumkov

User

Send message
Вы правы, у меня точно проблемы с восприятием. Исправил.
Все верно, адапетр Редиски тут не причем, дело в том что действительно в Zend_Queue такого метода нету, он есть только у адапетров: $queue->getAdapter()->isExists('test7');

Zend_Queue — далека до совершенства :)
Адаптер в Редиске реализует интерфейс Zend_Queue и не более того. Поэтому все архитектурные кляузы принадлежат к кривоватому по моему мнению Zend_Queue.
Вы заблуждаетесь. Редиска не кеширует в себе очереди.
Все тут так. Ознакомьтесь с интерфейсом Countable.
К слову, в библиотеке Rediska есть специальный адаптер для того, чтобы работать с очередями поверх Redis, но промучившись неделю и так и не заставив работать даже тестовый пример, я окончательно решил — все, пишу свою систему!

Очень странно мы успешно используем! Что у вас не работает?
Еще одним замечанием об архитектуре и отличиях от Rediska_Queue будет то, что насколько я понял из исходников, в угоду быстродействию, они положили ценное свойство распределённости. Например, команда getQueues, которая возвращает массив всех хранимых очередей (не сообщений, а только имена очередей), работает с локальной копией списка очередей. Поэтому, если другой клиент создаст новую очередь во время работы первого, он об этом не узнает.

Вы заблуждаетесь. Советую заглянуть глубже, перед тем как делать какие-то выводы.
Простите а как вы получили такие результаты? У нас прирост производительности получился очень незначительный.
К сожалению сейчас это не имеет никакого смысла. Читайте мой комментарий ниже.
Все верно, делает запрос при каждом добавлении. Redis пока не поддерживает операции множественного добавления элементов в списки. Поэтому сейчас нету разницы, отправлять по мере поступления или отправлять все сразу.
Получается вот так?

class Communities
{
    public function findCommunities()
    {
        $community = new stdClass();
        $community->id = 1;

        return array($community);
    }
}
class Cache_Tag_Communtity extends Geometria_Cache_Frontend_Tag 
{
    public function __construct($community)
    {
        parent::__construct("community_{$community->id}");
    }
}
class Cache_Slot_Communities extends Geometria_Cache_Frontend_Slot 
{
    public function __construct()
    {
        parent::__construct('communities', 60 * 60);
    }
    
    public function save($communities)
    {
        foreach ($communities as $community) {
        	$this->addTag(new Cache_Tag_Communtity($community));
        }

        return parent::save($communities);
    }
}

$slot = new Cache_Slot_Communities();
$communities = $slot->thru(new Communities)->findCommunities();
С использованием слотов для хранения в кеше одного объекта все понятно.
А что если я хочу хранить коллекцию объектов?
Можно посмотреть на это решение?
Точно! Вообщем это аналогичное второму варианту решение, но лишенное недостатка отключенных картинок в броузере и не надо колдовать с заголовками при отдаче картинок.
Правда ифреймы могут блокироваться экстеншенами броузера, которые занимаются безопасностью и рекламой.
Авторизовавшись на одном проекте, вы авторизовываетесь сразу на всех.
Авторизовавшись на одном нашем проекте, вы авторизовались сразу на всех.
Я так понимаю что доступ к ресурсам порталов только для зарегистрированных пользователей. Тоесть при входе всегда спрашивается логин. Я писал что варианты интранета я не рассматривал, так как наши проекты имеют публичный доступ.
Вы меня не правильно поняли, в первом варианте я говорю о проблеме авторизации по кукам. Вы залогинились и кука поставилась на домене site1.com и сервере авторизации. Вы зашли на другой наш проект site2.com. Там кука не стоит. Чтобы поднять авторизацию вас автоматически редиректит на сервер авторизации и проверяется есть ли кука, если есть то идет обратный редирект и ставится кука на site2.com. Вы авторизованы. Если куки не принимаются, то редирект будет происходить каждый ваш реквест на site2.com.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity