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