GitLab

Throws exception on UPDATE fails.

We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.

To set Avatar max size, adjust $config['avatar']['maxsize']

The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!

New Exception class added (MethodNotImplementedException)

This will return a proper DB_DataObject instance (as the desired class)
and not an array, or ArrayWrapper.

Memcached_DataObject now defines
   * pkeyGetClass to avoid collision with Managed_DataObject pkeyGet
   * getClassKV to avoid collision with Managed_DataObject getKV

I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV

   sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)

If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!

This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)

Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.

Compatibility: get_called_class is implemented in PHP >= 5.3.0

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. :)

Fix for caching with compound keys: add Managed_DataObject::_allCacheKeys() to override the one in Memcached_DataObject.

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.

Tweaking request_queue -> group_join_queue, easier to deal with the indexes and keys and caching this way.

first pass at columndef->drupal-style array converter (need to handle some more things probably; untested)

Managed_DataObject initial sketches (pulling Drupal-style schema def into the data that DB_DataObject and Memcached_DataObject use; not yet functional. Converted OStatus_profile for demo.)