[buddypress-trac] [BuddyPress] #3819: Create An Activity Lookup Table
buddypress-trac at lists.automattic.com
buddypress-trac at lists.automattic.com
Thu Dec 8 20:07:55 UTC 2011
#3819: Create An Activity Lookup Table
Reporter: jeffsayre | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Core | Version:
Severity: normal | Keywords:
There are a few instances where BuddyPress stores data that are not easy
for a developer to utilize in specific, meaningful ways. One such case is
that of activity groups and their associated actions. These get stored in
memory in the $bp->activity object array (the $bp->activity->actions
subelement for action items). These crucial data are not stored in the
database. It could be viewed as phantom data that is internally hardcoded
into the core code.
Instead of using lookup tables, key/value pairs are used to store activity
datasets in object arrays that are rebuffered into memory each time a page
is loaded. Hardcoding data like this can make it very difficult, if not
impossible, for 3rd-party plugins to interact consistently with and store
meaningful data based on this internal data.
Why is this an issue? If activity data is changed in the future -- via a
change in the hardcoded activity group names or activity action names --
any stored data (in a 3rd-party plugin’s table) that counts on a
particular activity item to have a particular name could lose integrity.
For instance, the “New friendship created” activity item (action) which
was internally coded as the action “friendship_accepted” in an older of
version of BP, was renamed to “friendship_created” in Changeset 1749. This
single change could have caused data instability in any 3rd-party plugin
that utilized the older activity items in their custom tables.
This method of storing activity data in memory (arrays) was implemented in
this [http://buddypress.trac.wordpress.org/changeset/1749 BP Trac ticket].
It was an attempt to offer a mechanism with which to manage activity
privacy. But after much testing and trial and error, this solution did not
present any easily-accessible, stable method to manage activity privacy on
a user-by-user basis. To make this method work for my component BP
Privacy, I would have had to either add a special column to the privacy
table just for this single piece of datum or create an entirely separate
table solely for activity privacy. Even then, the data stored in that
table could not be counted on remaining accurate (as detailed above).
''On a side note: It is interesting to note that all activity actions,
except the single one coded for the friends component, are used in the the
activity stream table. However for the friends component, the stored
activity action of “friends_register_activity_action” is not used. Instead
“friendship_created”, an action that is not officially registered with the
$bp->activity->actions array, is used. This should be changed.''
It is crucial to offer unique identifiers for all core pieces of datum.
With a unique identifier for activity data -- based off of the proposed
activity lookup table’s auto-incremented ID field -- it would be more
unlikely that any activity data stored via 3rd-party plugins could become
orphaned in the future by changes made to BP core’s values.
As an example, the Xprofile component offers unique field group IDs and
field IDs by virtue of the auto-incremented ID field in their respective
database tables. The Group component does so as well. But BP’s activity
component does not offer unique numeric identifiers for activity groups
nor activity actions. Instead, each activity item is stored in volatile
memory. This makes it difficult for a developer to count on activity item
data to never change.
Currently, a developer wishing to offer customized activity filtering
based on BP core’s activity names or activity actions must create their
own way to uniquely identify and index activity items. Since activities
and their associated actions are not stored in a table in the database,
there is no safe and stable way to assure that a particular piece of
activity datum will not change in the future.
Instead of storing activity groups and their associated activity actions
in volatile memory, I propose that BP switches to using an activity lookup
table. See the attached image for an example.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3819>
More information about the buddypress-trac