Constraints on Key Format?

[Brad Fitzpatrick]

Indeed, spaces can't be part of keys.  I believe this is documented in the
protocol document.  You can map it to about any other binary character,
though...  some APIs do this for you.


On Thu, 28 Jul 2005, Marcel Holan wrote:

> Hello,
>
> Disclaimer: not sure whether this is a bug or a feature, I wasn't also
> able to find a similar topic in the Archives - but then again, I'm a
> quite novice user of memcached (via the Perl-API - both newest
> versions) so I certainly might have missed something.
>
> It seems the key string cannot be any arbitrary string. At least I am
> not able to issue a
>
> $memd->set("KEY 1",$out);
>
> but have to replace the space with e.g. "_"
>
> Is there any specific reason for this? I wanted to cache results of
> (some) CLI-commands sent to a TCP server by the command string, which
> of course contains spaces.
> The problem with replacing spaces is twofold:
>
> 1) performance: transforming key on store/retrieval puts unnecessary
>    strain on the system
> 2) syntax: the CLI syntax assumes spaces as integral part, it allows
>    for almost any other char to be present, so it would not be
>    sufficient to simply replace space to something else, but I'd have
>    to start with some escape sequences making the performance issue
>    even worse.
>
> Any hints?
>
> --
>  best regards
>   Marcel Holan
>
>  project manager R&D
> +----------------------------------------------------------------------------+
>  PetaMem s.r.o., Ocelarska 1, 190 00 Praha, Czech Republic - www.petamem.com
>
>