It would be nice to be able to add multiple tags with a single commands :
add_tag(key, tag1, tag2, ..., tagN), to avoid multiple roudtrips, or add a tag
list as an optionnal parameter to the set/add/replace commands. ie : set <key>
<flags> <exptime> <bytes> <tag1>,<tag2>,<tag3>...\r\n
AFAIAC, I think tags need to be released. My use for tags would be to tag cache
entries by content id/user id/channel id. Having to store every id used (even
deleted content/content not accessed for a long time) since the last start of
memcached would be a problem...
I did not have enough spare cycles to think about the invalidation process...
Jean-François
________________________________
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dustin
Sallings
Envoyé : jeudi 4 octobre 2007 01:17
À : Memcached list
Objet : tag proposal
Tags seem to be getting hot and lots of people have talked about it
fairly abstractly. I wanted to try to bring some of those together with
respect to a memcached implementation and sit back and watch it all happen. :)
Firstly, I think there are two new commands to implement tags:
1) add_tag (key, tag_name)
2) invalidate_tag (tag_name)
I don't think there's a need for tag inspection for a given object.
There is *definitely* no command to search by tag.
All of the actual tags (text) would exist in a global hash table whose
value is a generation number.
[It's unclear whether it's worth the effort to ever release a tag once
it's been added. If we assume that tags live forever, we don't have to
refcount them and a few things get easier. Any opinions?]
A single global generation number is used to track invalidation events.
Each cache item contains a space for pointers to tags with their
individual generation numbers and a local generation number.
When a tag is added to an item, the global generation number is copied
into the item's local generation number (if it's not set), and the tag space is
extended to point to the tag key at its current individual generation.
Adding an existing tag to an item must not cause any modification to
the item (i.e. check first).
Invalidation of a tag would basically be a ``global_generation =
++tags[tag]'' kind of operation.
Each time an item is requested from a cache, the local generation
number is compared against the global generation number. If it differs, each
tag is checked to ensure the tag generation number equals the number stored for
that tag.
If they're all the same, the local generation number is set to the
global generation number.
If they're different, this record doesn't exist.
I've secretly left a lot of holes in this concept as a puzzle to the
reader. Three units of cool to each person who finds one.
--
Dustin Sallings
