Brion Vibber 1d15037d6a 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. :)
2011-09-29 15:21:52 -07:00
..
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 18:13:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-09-19 16:11:43 -04:00
2011-09-27 11:32:05 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-22 17:52:02 -04:00
2011-08-27 16:05:58 -04:00