memcache, изменение цепочек хэшей

Крот

Новичок
memcache, изменение цепочек хэшей

Еще раз привет!

Допустим, у меня есть БД с вот такой структурой (возможно не очень хороший пример, сорри)...

users
user_id
username
messages_new - кол-во новых приватных сообщений у пользователя
messages_incoming_total
messages_outgoing_total

messages
message_id
owner_id
recipient_id
body


В мемкэше я храню значение messages_new, messages_incoming_total, messages_outgoing_total
Когда пользователь A создаёт приватное сообщение пользователю B, то я должен обновить messages_new, messages_incoming_total, messages_outgoing_total у пользователя B и часть этих хэшей у пользователя A. (Я понимаю, что не очень разумно хранить такие значения в отдельных хэшах, но это только пример)

Таким образом, при создании нового приватного сообщения я должен запустить целую цепочку ф-ий, которые произведут необходимые изменения в хэшах мемкэша (да, конечно - тэгирование помогает определенным образом, но это в структурном плане, а не в реализации). Согласитесь, что не очень удобно пихать вызов этих ф-ий прямо в ф-ию добавления приватного сообщения в БД.

Как быть в таком случае?
Возможно стоит вынести все цепочки в отдельный класс (а-ля handler'ы)?
Если да, то как передавать экземпляр такого handler'а в DataMapper (который ответственен за работу с БД)?

Ёлки палки, сплошные вопросы... извиняюсь.

Спасибо!
 

zerkms

TDD infected
Команда форума
Согласитесь, что не очень удобно пихать вызов этих ф-ий прямо в ф-ию добавления приватного сообщения в БД.
и не надо. пусть по тегам кеши сбрасываются, а обновляются по первому запросу.
 

Крот

Новичок
Ну вообще да, зачем хранить те данные в мемкэше, которые неизвестно еще будут ли использованы и тем более как-то модифицировать их. Удалять проще - согласен.

Спасибо!
 

Крот

Новичок
А как их помечать? Добавлять тэг invalid? Ведь это сродни удали, создай заново.

Или просто ставить время жизни на прошлый timestamp и хэш сам откинется?
 

zerkms

TDD infected
Команда форума
Крот
я делаю так:
вместе с данными хранится массив тегов, в виде:
tag1 => tag1_rev
tag2 => tag2_rev

также каждый тег это отдельный специальный ключ, который хранит ревизию. при необходимости сбросить тег - просто инкрементируешь его и всё, данные протухают

например:

[a] => array(data => 'полезные данные',
tags => array('a' => 10, 'b' => 2));

т.е. в "ячейке" "a" хранятся "полезные данные" и версии тегов, 10 и 2 соответственно.
также есть ячейки:
[tag_a] => 10
[tag_b] => 2

При извлечении данных проверяешь, что ревизия актуальная. Если нет - то данные неактуальны.
При необходимости сброса данных - просто увеличиваешь соответствующий тег:

[tag_a] => 11 и всё, при следующем извлечении данных они будут признаны невалидными.

-~{}~ 06.10.09 19:59:

пока писал, дали ссылку на ту же технику :))
 
Сверху