On Oct 4, 2007, at 6:25 , Tobias Lütke wrote:
Once tagging is available however collections can be cached directly.
Collections will be tagged with the key for each article contained.
Very complex queries can now be simply cached dumped into memcached
because they can be invalidated by a simple command.
Simply override the cached key for the article by re-setting it and
issue a tag invalidation on the same key:
Cache.set('article:1', a)
Cache.invalidate_tag('article:1')
This also means that the number of tags in the system will be quite
large. There will be one or more tags for each row in the articles
table. I expect the amount of tags to be vastly larger then the amount
of keys in future memcached servers.
I think that's *a* use, but I don't know that it's necessarily the
primary use. It's more of an argument for cleaning up tags when
we're done with them, though. It doesn't change much of the original
proposal other than confirming that we do, indeed need to clean them up.
On 10/4/07, Dustin Sallings <[EMAIL PROTECTED]> wrote:
On Oct 4, 2007, at 1:07, BUSTARRET, Jean-francois wrote:
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
I don't think there's a problem with multi-tag. I'd expect
people would
want to have more than one anyway.
Adding tags to all of the existing commands is a tough one,
though. The
cost of one more round trip is trivial compared to having to
change the
server processing of mutation commands and updating all of the
client APIs
to be able to handle this. In a particular client, you can still
send both
commands as a single stream and then just expect two lines of
response.
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...
OK, it's worth considering, then.
Each tag will have a reference count that is increment every time
the tag
is successfully added to an item (i.e. must not increment if an
item lookup
fails or the item already has the tag).
When the item is deallocated, all tags should be decremented for
that item.
When the tags reference count hits zero, we'll pull it from the
global map.
Memory churn may be an issue. Someone who knows allocators
better than I
do can decide what to do here.
--
Dustin Sallings
--
Tobi
http://shopify.com - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog
--
Dustin Sallings
