| | 109 | - Moving last_activity to the activity tables is problematic because the Activity component is optional. If it's disabled, we don't have the tables, and we don't have the functions that write to the tables. So if we go this way, we either have to make Activity required, or maintain two different sets of query logic - one that uses Activity, and one that doesn't (which would, I guess, be the crappy version we have now). I'd rather go with making Activity required, but that will take a bunch of other kinds of work. An alternative approach is to store last_activity in a standalone table structured just like wp_bp_activity when Activity is disabled, which would still enable Activity to be turned off. The problem there is what would happen if someone decided to switch Activity on and off. Or we could just use a totally separate table, as originally suggested by shanebp, but that seems like a waste to me - we already have an activity table structure in place. |