[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