[buddypress-trac] [BuddyPress Trac] #5572: last_activity migration function is unnecessarily slow

[buddypress-trac]

#5572: last_activity migration function is unnecessarily slow
--------------------------+--------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.0.1
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by boonebgorges):

 Thanks for the feedback, DJPaul.

 > If a user has last_activity in the activity table but not in usermeta.
 Does this situation exist in any way in core at the moment?

 No. We always mirror it. It would only come up if a plugin directly
 updates the usermeta row.

 > If it did, users affected wouldn't show up in member lists etc until
 that user's logged in and BP's regenerated the key, which seems acceptable
 to me as a consequence of this (hopefully) once-off migration.

 Correct, and I agree that it's an edge case consequence that is not the
 end of the world.

 > We're deleting the records directly in the database. Do we need to clear
 any caches?

 It'd slow things down a lot to delete the caches. I don't think we need
 to, in any case. The usermeta cache for 'last_activity' is only read if a
 theme or plugin directly calls `get_user_meta( $user_id, 'last_activity'
 )`. BP core does not do that anymore - all last activity data is queried
 from the activity table. So, it's highly unlikely that anyone will ever
 see the stale cache data, and in any case it will be purged the next time
 the user in question logs in.

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