Hackathon / Multidimensional keys / Wildcard deletes

[Dustin Sallings]

	There'd be indexing overhead, but you could have an O(1)  
invalidation if the tags themselves were versioned.

	Assuming the cache time is short or you're accessing these records,  
cleanup should pretty much take care of itself.

	Protocol-wise, would it make sense to have the tags be additional  
tokens on the mutation line?  i.e.:

	<command name> <key> <flags> <exptime> <bytes> [<tag> [...]]\r\n

On Jul 6, 2007, at 6:14, Jan Miczaika wrote:

> Hello,
>
> I saw these proposed features for the Hackathon. Unfortunately I  
> can't take in person, wrong continent for me.
>
> I would like to suggest a feature which would probably address  
> these issues well: tagging keys. Each key would have 0...n tags  
> assigned to it. Flushing keys could be done by asking memcached to  
> flush all keys with a certain tag.
>
> The usage scenario: lets say we have a DVD. We have a number of  
> keys related to this dvd, maybe recommendations, comments,  
> categorization etc. I could tag each of these keys with the id of  
> the DVD (dvd:1234). Then I would tell memcached to flush all keys  
> with the tag dvd:1234, causing the database to recalculate all data  
> relating to dvd 1234 on the next access.
>
> Zend implemented similar functionality in their new framework:
> http://framework.zend.com/manual/en/ 
> zend.cache.theory.html#zend.cache.tags
>
> The wildcard deletes could be done this way, more efficiently than  
> looping through the whole cache to see if a regex matches.  
> Multidimensional arrays could be partially simulated by using tags.
>
> I hope someone is interested ;-)
>
> Cheers
>
> Jan
>
>
>
>
>
> -- 
> Geschäftsführer / Managing Director
> Hitflip Media Trading GmbH
> Gürzenichstr. 7, 50667 Köln
> www.hitflip.de - new: www.hitflip.co.uk
>
> Tel. +49-(0)221-272407-27
> Fax. 0221-272407-22 (that's so 1990s)
> HRB 59046, Amtsgericht Köln
>
> Geschäftsführer: Andre Alpar, Jan Miczaika, Gerald Schönbucher
>

-- 
Dustin Sallings