Notes from the fourth memcached hackathon of undetermined frequency

[Dustin Sallings]

On Apr 16, 2008, at 15:22, mike wrote:

> On 4/16/08, Dustin Sallings <dustin at spy.net> wrote:
>
>>       * get   (returns an object or error; does not return key)
>>       * getq  (returns an object; does not return missing; does not  
>> return
>> key)
>
> is the "q" something like "get quietly" ?

	Yes, it's the quiet get we defined from the first meaning.  It only  
returns data, never returns anything on a miss (but could signal an  
error).

>>       * getk  (returns an object with key or error)
>>       * getkq (returns an object with key; does not return missing)
>
> Do any of these return a "cache miss" message, or does it only return
> if there is an error? If I read this right, "get" and "getk" both
> return a miss...

	That is correct.  You do not get a cache miss message for q commands.

> I could see client libraries benefitting from a "miss" message (for
> all I know it could already be in the protocol though and my client
> just doesn't do anything with it.)


	Clients and servers benefit greatly from *not* having miss messages.   
Imagine needing 1,000 keys for which only 100 are actually in the  
server.  You could issue 1,000 quiet gets and a noop (or 999 getq  
commands and a get) and only have to deal with hits.  The misses are  
implied.

	This is the same way the text protocol works today, except it's been  
generalized slightly more and made a bit easier to deal with by not  
having to have one command that takes an arbitrary number of variable  
width keys that the server has to understand how to separate.  All the  
server wants to know is whether you want a response on a miss, and  
(now) whether you want the key returned as well.

-- 
Dustin Sallings