[buddypress-trac] [BuddyPress Trac] #7245: Updating user last_activity doesn't bust activity query cache

[buddypress-trac]

#7245: Updating user last_activity doesn't bust activity query cache
------------------------------------+------------------
 Reporter:  boonebgorges            |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  2.7
Component:  Members                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch dev-feedback


Comment:

 [attachment:7245.diff] is a straightforward fix for the problem. It
 ensures that the bp-activity incrementor is busted every time a user's
 `last_activity` value is bumped.

 The downside of this naive approach is that it may result in a more
 shortlived cache than we might otherwise have. Consider a community where
 lots of people log in to view content, but don't create much new content.
 Currently, activity queries are cached until a new activity item (other
 than `last_activity`) is created. With [attachment:7245.diff], even a
 single logged-in user visiting the site will invalidate the caches every
 five minutes. This may be somewhat of an edge case, since lots of logged-
 in users are probably likely to produce more "actual" activity, but it
 could still be an issue.

 A workaround could be to have a separate cache group for "normal" activity
 queries than for those that include `last_activity`. So the activity query
 cache would look something like this:

 {{{
 if ( false === strpos( $sql, "'last_activity'" ) ) {
     $group = 'bp_activity';
 } else {
     $group = 'bp_activity_with_last_activity';
 }

 $cached = bp_core_get_incremented_cache( $sql, $group );
 }}}

 The regular increment-busting function
 `bp_activity_reset_cache_incrementor()` would reset incrementor for *both*
 groups. But when updating `last_activity`, only the
 `bp_activity_with_last_activity` group would have its incrementor bumped.
 So the caches remain mostly separate.

 I'd like a second opinion about the following questions:
 (a) Is it overkill to worry like this about short-lived, shared cache
 groups?
 (b) If the concern is valid, does the approach described here seem like a
 sensible (if weird) one?

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