[buddypress-trac] [BuddyPress Trac] #7435: XProfile caching: The Next Generation

[buddypress-trac]

#7435: XProfile caching: The Next Generation
------------------------------+---------------------
 Reporter:  boonebgorges      |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  4.0
Component:  Extended Profile  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |
------------------------------+---------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Contributions => 4.0


Comment:

 I've started work on this and would like to squeeze at least part of it
 into 4.0, if possible.

 [attachment:"7435.diff"] breaks up `BP_XProfile_Group::get()` somewhat, so
 that the group ID query and the field ID queries take place in different
 methods: `get_group_ids()` and `get_group_field_ids()`. They're meant for
 internal use, and are public only so that it's easier to test them. Each
 of them has its own caching layer, both of which are tied to the
 `bp_xprofile_groups` incrementor. I'm using the same incrementor for each,
 because any changes to *either* groups or fields can result in the queries
 being thrown off (because of `hide_empty_groups` etc). I'm then using the
 SQL statement to generate a cache key.

 I've made an attempt to cover the invalidation cases. I've erred on the
 side of too-much-invalidation: we bust the incrementor anytime a group or
 a field is saved or deleted. Updating field/group order also needs its own
 invalidation, because it doesn't run through `save()`.

 This thought process - especially invalidation - could use another set of
 eyes. Maybe @dcavins ? I can work on more caching, but what's suggested
 here would be a good start.

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