Further fixes to Managed_DataObject::_allCacheKeys(): now uses...
Further fixes to Managed_DataObject::_allCacheKeys(): now uses self::multicacheKey() to generate the (possibly compound) keys, which makes it match the order of the keys used when calling pkeyGet(). This should resolve the issues darkip was reporting with user_im_prefs entries returning null immediately after insertion (seen with memcached off, so it was happening even with the built-in in-process cache in the Cache base class). What was happening was that the initial pkeyGet() would end up saving a negative cache entry under the form with the fields sorted in the key, as via multicacheKey(): 'statusnet:blaguette:user_im_prefs:screenname,transport:brionv,sms' => 'N;' then we'd do an insert() on the new entry, saving cache entries for the non-sorted key names returned by _allCacheKeys(): 'statusnet:blaguette:user_im_prefs:transport,screenname:sms,brionv' => 'O...' 'statusnet:blaguette:user_im_prefs:user_id,transport:1234,sms' => 'O...' but the next query via pkeyGet() still saw the negative lookup cache from before, and came back with null. Now, _allCacheKeys() sorts the fields in the keys by using the same key-builder function, and queries pick up the same thing you just inserted. :)
Showing with 6 additions and 9 deletions