memcache(3) 1.2.0 released...
John McCaskey
johnm at klir.com
Wed Jan 12 11:17:51 PST 2005
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 at klir.com
206.902.2027
More information about the memcached
mailing list