[buddypress-trac] [BuddyPress Trac] #6327: Improved caching for group membership

buddypress-trac noreply at wordpress.org
Tue Mar 31 16:18:03 UTC 2015


#6327: Improved caching for group membership
--------------------------------+------------------
 Reporter:  boonebgorges        |       Owner:
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  2.3
Component:  Component - Groups  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |
--------------------------------+------------------

Comment (by DJPaul):

 Looks pretty good. I have not looked at the unit tests (yet).

 The new actions in class-bp-groups-member.php ought to be committed
 separately (as I'm sure you know/were going to do).

 I agree caching IDs and the objects individually is probably better, and
 it feels like it's worth the time investment to get it right:

 * I think it would match what we do in other parts of BP/WP? which seems
 to work well?
 * Storing "many" objects in one cache item could end up with a very large
 item in not unrealistic edge cases. Caching backends don't usually handle
 these well, or keep them cached for long due to the size.

 I don't quite understand enough why, for this, we would want to select
 everything and do the sorting in PHP, and everywhere else, do it across a
 few SQL queries. Would the "cache IDs and individual objects" approach
 mean changing this and doing in SQL?

 Not too bothered about argument type in `bp_get_user_groups` but would
 conservatively prefer something more consistent with our other functions,
 unless there's an angle I'm not seeing.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6327#comment:6>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list