Re: memcache(3) 1.2.0 released...

On Wed, 2005-01-12 at 10:59 -0800, Sean Chittenden wrote:
> > The one major complaint I have with the current php oo api's (and
> > possibly the Ruby api) are that they simply return FALSE (nil for 
> > Ruby?)
> > for an unfound key, thus breaking the ability to store arbitrary binary
> > data as I now cannot store a FALSE, or a binary equivalent in memcache.
> 
> Nope, you're good to go if you model after the Ruby API.  Ruby returns 
> nil for not found, true/false for booleans, and an empty string for 
> well... an empty string.  You can store a nil value, but fetching it... 
> well, returns a nil without you ever knowing if it worked or not.  This 
> is something that I'll address with the Memcache::Request object.
> 

Ahh, so I'm actually not quite good then as nil==NULL in php and I in
fact want to store and retrive these and know if they are actual NULL's
or misses.

> > Perhaps, I'll always return as an array('key'=>'value', ...,
> > 'keyn'=>'valuen') and the way to determine a miss is simply that the 
> > key
> > does not exist at all, and then NULL or FALSE are valid data from the
> > cache.
> 
> You could do that.  Actually, that's the best way to handle the 
> above... didn't think about that.

Yep it looks like this is what I'll do, add's a little overhead in
creating the array and checking for the existance of a key, but the
reliability is important to me.


> > If I did this as a php5 module, maybe I'd just throw an exception... 
> > but
> > alas I need to use php4.
> 
> Exceptions rule, especially if they're efficiently handled by the 
> language.  -sc
> 
-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm@xxxxxxxx
206.902.2027