[buddypress-trac] [BuddyPress Trac] #5407: Improvements to object caching in bp-groups

[buddypress-trac]

#5407: Improvements to object caching in bp-groups
--------------------------+------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  2.0
Component:  Groups        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------

Comment (by boonebgorges):

 johnjamesjacoby is correct. The caching happens here:
 https://buddypress.trac.wordpress.org/browser/trunk/bp-groups/bp-groups-
 classes.php?rev=8001#L223 We could do multiple layers of caching here if
 we thought it was worth the trouble (one for basic data, and another for
 populate_extras data). My thought is that it's *not* currently worth the
 trouble (which is why it currently works the way it does), but I'd be
 happy to discuss.

 > It's probably worth discussing how we query for and cache supplemental
 component data, both including and excluding meta.

 Metadata - in the technical sense of "stored in the meta tables" - should
 never be cached with the object. We have separate object caches for that.

 In an ideal world, we would have fine-grained caches for all other
 supplemental data - stuff like admins_mods_of_group_54. But this can be a
 lot of work, because it multiplies the amount (and different kinds) of
 invalidation we have to do. So, where it's easier, like in this case, I
 think it's fine to cache with the object.

 r-a-y - Just saw your point about secondary avatars. That would be the one
 place where populate_extras=false caching might make sense. If you feel
 like breaking it up into two layers of cache, please be my guest. (Please
 write unit tests for it :) )

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