[buddypress-trac] [BuddyPress Trac] #7237: Incrementor-based query caching for the Activity component

[buddypress-trac]

#7237: Incrementor-based query caching for the Activity component
--------------------------+------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  2.7
Component:  Activity      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch


Comment:

 [attachment:7237.diff] is a basic first pass at the functionality.

 - The main caching logic for the activity query itself is inside of
 `BP_Activity_Activity::get()`. As you can see, it's quite simple. I've
 opted to use the SQL string as an identifier for the query, since it's
 guaranteed to make queries unique, and will be a commonality across all
 components.
 - I believe that activity queries only need invalidation on activity
 addition, edit, and deletion.
 - bp-core-cache.php contains a couple new utility functions for setting
 and getting ID query caches. The implementation is designed to be fairly
 opaque for the developer - you don't need to know how it works under the
 hood, and you definitely don't need to know anything about incrementors to
 cache data in a able-to-be-invalidated-in-bulk way. (This is in contrast
 to WP, where all incrementors are done inline.) I'm happy to reconsider
 the naming and function signatures of these new functions, to make sure
 they accurately describe what they're doing.
 - The tests demonstrate that the basic caching is working properly. Let me
 know if there are edge cases I've missed.

 Would especially like feedback from @r-a-y and @dcavins, though I'd
 welcome comments from all.

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