Sequence cache

[dovg]

Вот такая штука у нас родилась.

Включает в себя (в порядке следования в diff):

• Assert::isObject()
• ленивое подключение в PeclMemcache
• таймауты коннекта и запроса в нем же
• SequentialCache - такой хитрый CachePeer, который объединяет пул кешей и делегирует get запрос slave при мертвом мастере. Пишет при этом во все кеши. Может быть полезно при нестабильной сети или нестабильном memcache (как в нашем случае :)
• тесты.

Тесты проходит.
Вольем?

[crazedr0m]

А можно не трогать PeclMemcache ?
По тестам не видно что SequentialCache работает с чем-то кроме PeclMemcache, при этом у него в параметрах можно передать любой CachePeer

[dovg]

А можно не трогать PeclMemcache ?

Почему? BC же сохраняется.

По тестам не видно что SequentialCache работает с чем-то кроме PeclMemcache

Поддерживаю, добавим.

[crazedr0m]

Не догнал. То есть в процессе работы мы можем менять параметры подключения - хост, порт, таймаут?
И после того как мы установили соединение $this->instance->pconnect() или $this->instance->connect() мы еще раз устанавливаем таймаут?
Зачем?

[dovg]

То есть в процессе работы мы можем менять параметры подключения - хост, порт, таймаут?

Не, не. Смысл в том, что подключение производится только при необходимости.

мы еще раз устанавливаем таймаут?

Это ошибка. На самом деле там два вида таймаута - таймаут на подключение и таймаут на запрос. Можно задать оба.

[crazedr0m]

Ну да, не заметил что $this->instance->setServerParams() а не $this->setServerParams(),

[crazedr0m]

Меня все-таки смущает "ленивое подключение", не могу обосновать, что-то на уровне эмоций )
Почему именно в этом пире а в остальных нет?
Если это связано с тем что не к каждому слейву нужно подключаться SequentialCache то может это все-таки логика SequentialCache ?
Или может быть имеет смысл сделать посредника который сможет работать с любым пиром?

[dovg]

Почему именно в этом пире а в остальных нет?

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

Если это связано с тем что не к каждому слейву нужно подключаться SequentialCache то может это все-таки логика SequentialCache ?

Это может быть полезно для последовательного кеша и всех реализаций аггрегатных кешей. Допустим у тебя 10 пиров в AggragateCache, но за время жизни скрипта ты делаешь всего один get к ним. Зачем еще 19 подключений? Это же трата ресурсов.

Или может быть имеет смысл сделать посредника который сможет работать с любым пиром?

У нас была задумка сделать декоратор/прокси - LazyObject, который бы делегировал все вызовы внутреннему классу, создавая его при первой необходимости. Но там оверхед получался.

ps. Тесты сейчас добавлю.

[crazedr0m]

А если мне не нужно "ленивое" подключение, я должен сразу после создания дернуть какой-нибудь метод, например isAlive() ...
Ну может и так. Но мне все равно не нравится )

[dovg]

А если мне не нужно "ленивое" подключение,

А зачем тебе это? ;)

[dovg]

Обновил тесты, теперь они стали более лучше одеваться^W объяснять примеры использования.

[AlexeyDsov]

Все смотрю и задумываюсь - а надо ли в конструкторе добавлять новый аргумент? Может правильней было б его через отдельный setter задавать. Тем более что в этом lazy варианте теперь соединение устанавливается не в конструкторе.

[dovg]

Мы же пишем враппер для http://ru2.php.net/manual/en/memcache.connect.php, там в конструкторе три параметра. Я тут ничего плохого не вижу. Алсо есть значение по-умолчанию, что дает сохранение обратной совместимости.

[AlexeyDsov]

@dovg разве до изменений оно коннектилось с таймаутом? Теперь же если создавать так же с двумя параметрами класс, то коннектиться к мемкешу он будет с тайматом.

[AlexeyDsov]

Хм, не прав. BC сохраняется в этом случае тоже.

[dovg]

Друзья, если нет возражений по существу, то я это волью.
Спасибо за понимание :)

[AlexeyDsov]

тут слэшик лишний, пожалуй. и еще кой-где в diff'е встречается этот признак нетбинса

[dovg]

закрываю в пользу #93