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. :)
Memcached_DataObject doesn't quite fully understand unique indexes, and can't properly build cache keys for compound unique or primary keys.
Managed_DataObject has more information in its schema data, so we can build a proper list.
* '1.0.x' of gitorious.org:statusnet/mainline:
Issue #546: enable case-insensitive searching in MySQL
remove more groupnav
remove group nav
shorter title for tag cloud section on groups
remove group nav
move pending queue to sidebar
Move group logo edit from object nav to block actions
Show blocked users from group in section
MySQL needs the collation utf8_general_ci to support case-insensitive
searching. lib/mysqlschema.php already supports a 'collate' attribute on
a per-column basis, so we just need to take advantage of that attribute
on the columns we want to search and Bob (and BOB, and bOB) is your
uncle.
Signed-off-by: Dan Scott <dan@coffeecode.net>
