tag proposal

[BUSTARRET, Jean-francois]

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 : memcached-bounces at lists.danga.com [mailto:memcached-bounces at lists.danga.com] 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071004/0a35c5be/attachment.html