ZF-9376: Memcache::delete reports notice with memcached 1.4.4

Description


$mc = new Memcache();
$mc->addServer('127.0.0.1', 11211, false, 1, 1, 15, true, null);

$mc->set('test', 'testdata');
var_dump($mc->get('test'));
$mc->delete('test');
var_dump($mc->get('test'));

string(8) "testdata"
PHP Notice:  MemcachePool::delete(): Server 127.0.0.1 (tcp 11211, udp 0) failed with: CLIENT_ERROR bad command line format.  Usage: delete  [noreply]
 (0) in /tmp/test.php on line 8
bool(false)

Changing this to $mc->delete('test', 0); will fix this issue:


$mc = new Memcache();
$mc->addServer('127.0.0.1', 11211, false, 1, 1, 15, true, null);

$mc->set('test', 'testdata');
var_dump($mc->get('test'));
$mc->delete('test', 0);
var_dump($mc->get('test'));

string(8) "testdata"
bool(false)

http://code.google.com/p/memcached/… : Fixes Add partial backwards compatibility for delete with timeout 0

Before version 1.4.0, there was an optional argument to delete that would allow a client to specify that a deleted object should exist in the cache after the deletion occurred such that add operations would fail even though objects did not appear in the cache.

This feature was removed completely in 1.4.0, but a parser bug caused it to slip through. The bug was fixed in 1.4.3. If anyone was attempting to use it legitimately in the 1.4 series, it would simply not work as expected.

The 1.4.4 backwards compatibility change allows specifically the value of 0 (i.e. non-lingering delete), while continuing to reject others. This will satisfy clients that always wish to send a value even when they do not wish the item to linger.

Comments

fixed in r21420 (trunk) & r21421 (1.10 branch)