[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