tag proposal

[Dustin Sallings]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071004/546066b0/attachment.htm