[buddypress-trac] [BuddyPress] #3819: Create An Activity Lookup Table

[buddypress-trac at lists.automattic.com]

#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>
BuddyPress <http://buddypress.org/>
BuddyPress