[buddypress-trac] [BuddyPress Trac] #3856: Saving activity update action as an array in db

buddypress-trac noreply at wordpress.org
Sat Mar 1 03:16:34 UTC 2014


#3856: Saving activity update action as an array in db
-----------------------------------+------------------
 Reporter:  modemlooper            |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.0
Component:  Activity               |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch 2nd-opinion


Comment:

 OK, I have a proof-of-concept for this. See 3856.01.patch. Basically:

 - When registering actions with `bp_activity_set_action()`, include a
 'format_callback' param
 - When saving activity items, stash useful concatenated info into a piece
 of activitymeta called 'action_data'. Stuff like: userlink, grouplink, etc
 - When querying activity items, populate the 'action' property with the
 function `bp_activity_generate_action_string()`. That function looks up
 the format_callback registered for that activity type, and then passes the
 activity object along to the callback
 - I've implemented two examples of formatting callbacks:
 `bp_activity_format_activity_action_activity_update()` and
 `bp_groups_format_activity_action_joined_group()`

 The technique seems to be working well. No real overhead is added, since
 activitymeta is already pre-fetched within activity loops.

 The 'action_data' technique is my way of caching expensive data.
 (Remember: caching expensive data was the reason for storing an action
 string in the first place.) I've based in it part on the way that WP uses
 '_wp_attachment_metadata' postmeta to store stuff. However, the more time
 I spend thinking about the callback technique, the more I begin to
 envision ways that we could avoid most of this action_data caching. For
 example, it wouldn't add much overhead to fetch display names and user
 links for all users at the beginning of an activity loop, in the same way
 that we pre-fetch a bunch of other data. (This becomes even less of a
 worry now that we've improved our object caching so much.) However, some
 data - especially the names and URLs of posts from other blogs - will
 always have to be stored somehow, as it's probably never going to be
 feasible to grab it on the fly.

 It'd be great to get initial feedback on the technique I've sketched here.
 Thanks.

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


More information about the buddypress-trac mailing list