[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