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

[buddypress-trac]

#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              |   Keywords:
--------------------------------+-----------------
 There are two broad scenarios where you may want to query for group
 memberships: (a) when you want to know which members a group has, and (b)
 when you want to know which groups a member belongs to. The query and
 caching strategies for the two scenarios are different, and in this ticket
 I'm talking only about (b).

 There are many weird, ad hoc ways that we query for user-group memberships
 in BP. `groups_is_user_member()` etc do direct SQL queries.
 `bp_has_groups()` with a 'user_id' param does a JOIN against the
 membership table. `groups_get_user_groups()` does another type of direct
 SQL query. `groups_total_groups_for_user()` does yet another SQL query.
 And so forth.

 With the exception of `groups_total_groups_for_user()`, none of these
 queries are cached. I've run into this problem recently when building a
 plugin that pulls up a list of groups and does membership checks for the
 groups, sometimes for different users at different times on the page. The
 obvious answer - `groups_is_user_member()` - results in a separate SQL
 query for each call, which can add up to hundreds on a single page load.

 After thinking about this for a while, I'd like to recommend the following
 strategy. Let's do maximal caching of group memberships, on a per-user
 basis. That is, we'll cache the results of `SELECT * FROM
 $bp->groups->table_name_members WHERE user_id = 12345`. Then provide a
 utility function for getting this information - filtering it based on
 `is_mod`, `is_confirmed`, sorting - all of which will be done in PHP, on
 the cached data, rather than in a SQL query. Then, start to refactor a
 bunch of these functions to use the central utility function.

 I'm working on patch for this and will post it soon. In the meantime,
 thoughts are welcome, and I'll use this ticket to commit some preliminary
 unit tests.

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