Hackathon notes (non-binary protocol thread)

BUSTARRET, Jean-francois jfbustarret at wat.tv
Wed Jul 18 07:42:01 UTC 2007


> -----Message d'origine-----
> De : Dustin Sallings [mailto:dustin at spy.net] 
> On Jul 17, 2007, at 11:21 , BUSTARRET, Jean-francois wrote:
> 
> > - add "char* tags" to the _stritem struct
> > - store tags in a comma/whatever-delimited string :  
> > ",tag1,tag2,tag3," (space and comma being reserved), the 
> client being 
> > eventually responsible for formatting the tag string
> > - modify the protocol to add an optional tag parameter <command
> > name> <key> <flags> <exptime> <bytes>[ <tags>]\r\n
> > - add a new deletetag command ?
> > - delete items using the same rule approach as described by Dustin,
> > strpos-ing(",tag,") instead of regexp-ing the key Multi-tag deletes 
> > can be split in multiple rules
> >
> 
> 	That's a good start, and it seems that it could work.  
> I'd be concerned that you're storing a lot more information 
> in a lot more places, though.  If you just stored the tags in 
> the key and used the regex cleanup, you'd get the same effect 
> without changing the storage strategy too much and without 
> having to do any protocol modification other than adding the 
> delete-by-pattern command.
> 

We could store tags within the key... But the get would have to ignore
the tags.

set key,tag,tag,tag value...
get key => value

My first idea was to trick assoc_find by storing nkey as the length of
the key, without tags (instead of strlen(key)), but having strlen(key) >
nkey might be dangerous, we could add another "keysize" field, and have
one for memory management, one for key comparison.

JFB


More information about the memcached mailing list