[buddypress-trac] [BuddyPress Trac] #3794: Deleted activity items remain favourited

[buddypress-trac]

#3794: Deleted activity items remain favourited
--------------------------+------------------
 Reporter:  ewebber       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.7
Component:  Activity      |     Version:  1.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------

Comment (by boonebgorges):

 Thanks for continuing to work on this, @imath.

 If I understand correctly, you're adding a new line in *usermeta* for each
 favorited activity. That means that if you have 10,000 users with 10
 favorites each, you'll be adding 100,000 rows to usermeta. Usermeta is a
 table that's already subject to bloating and poor performance due to
 plugins that put lots of data in there. This problem is compounded at
 scale, when the users tables are global and shared between many networks.

 At some point in the future, BP will have an item-to-item relationship
 API, and at that point, Favorites will be an obvious use case. So I think
 what we're trying to do here is come up with something that fixes the bug
 for now, without introducing too many scaling problems or requiring a huge
 amount of additional work.

 The nice thing about the proposed usermeta solution is that operations
 like `add_user_meta()` are fast. But it has the potential to cause more
 global performance problems. Could we get away with doing something a bit
 less elegant, which would be a bit slower at the time of adding/deleting
 favorites and/or activity items, but would not cause global slowness?
 Something like:

 {{{
 // adding favorite
 $favs = bp_get_user_meta( $user_id, 'bp_favorite_activities', true );
 $favs[] = $activity_id;
 bp_update_user_meta( $user_id, 'bp_favorite_activities', $favs );

 $fav_users = bp_activity_get_meta( $activity_id, 'favorited_users', true
 );
 $fav_users[] = $user_id;
 bp_activity_update_meta( $activity_id, 'favorited_users', $fav_users );

 // deleting activity item
 $fav_users = bp_activity_get_meta( $activity_id, 'favorited_users', true
 );
 foreach ( $fav_users as $fav_user ) {
     bp_recount_activity_favorites_for_user( $fav_user );
 }
 }}}

 This may cause issues if a specific activity item is favorited by many
 users. In that case, we may have to have a system for resetting in
 batches. But it feels like a more modest architectural change than the
 huge amounts of green and red in [attachment:3794.05.patch], especially
 since it's designed to be a temporary solution. (I know that much of the
 green/red in [attachment:3794.05.patch] is due to moving stuff to a new
 file - it's pretty hard to tell what's new and what's old when it's all
 part of a single patch.)

 @imath Is this a bad suggestion? Is there a way we can decide what
 strategy to take without you having to sit down and write a mountain of
 code? :)

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