[buddypress-trac] [BuddyPress Trac] #7477: BP_Groups_Group::group_exists() should be cached.

buddypress-trac noreply at wordpress.org
Wed Mar 29 21:16:15 UTC 2017


#7477: BP_Groups_Group::group_exists() should be cached.
------------------------------------+-----------------------
 Reporter:  dcavins                 |       Owner:  dcavins
     Type:  enhancement             |      Status:  accepted
 Priority:  normal                  |   Milestone:  2.9
Component:  Groups                  |     Version:  2.8.2
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+-----------------------

Comment (by dcavins):

 Thanks for your comments, @r-a-y!

 I'm assuming that the better method is the .2 and .3 diff strategy which
 uses `BP_Groups_Group::get()` internally.

 In that case, if group A's slug is changed via
 `groups_edit_base_group_details()` ( per the routine in #6014), then the
 action `groups_details_updated` will be triggered, so Group A's specific
 cache entry will be deleted.
 https://buddypress.trac.wordpress.org/browser/tags/2.8.2/src/bp-groups/bp-
 groups-cache.php#L64

 Either approach also relies on the cache incrementor--whether I'm calling
 it directly or `get()` is. As far as I understand, the cache incrementor
 is reset when the `groups_group_after_save` action is called, so queries
 after a group is updated will miss the cache and need to be re-run since
 the group table or meta table has been changed in a meaningful way.
 https://buddypress.trac.wordpress.org/browser/tags/2.8.2/src/bp-groups/bp-
 groups-cache.php#L257

 Am I understanding that correctly?

 Thanks!

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


More information about the buddypress-trac mailing list