Feature proposal #8457open
Implement relational tables
Currently when commenting on an activity entry it creates an activity entry per comment then groups them during PHP. Replace this with a relational table that allows stacking users against a single activity entry. This would result in 1 activity row which is the comment row that is owned by the person who created the activity next in the relational table there will be users who commented on that activity. This should use a unique primary index as well with the following table structure.
activity_id | user_id
Next for Notifications get rid of the user column and replace it with a relational table. That table will determine who is getting the notification. This will allow sending a single notification to multiple users. It should be similar to the above as follows.
notification_id | user_id
Comments, Likes, and Follows don't need a relational table.
The only remaining issue is things like CB Gallery when uploading multiple gallery items at once we really only want to create a single activity entry instead of multiple that are grouped in PHP. The only real way to do that is probably move object | object_id to a relational table, but that might be inefficient. Another option is create 1 activity entry and just log the other gallery ids into that 1 entry.
Updated by krileon over 1 year ago
- Target version changed from 6.0.0 to 7.0.0
Unlikely to need this as the amount of stored information as is is very minimal. The JOIN would probably hurt performance more than just having extra rows.
Updated by krileon 30 days ago
- Status changed from Assigned to Resolved
- Target version changed from 7.0.0 to 6.0.0
- % Done changed from 90 to 100
Implemented for mentions (activity and comments), tags (activity), hashtags (activity), liked (activity), and notifications. Doesn't seam to be a need for others at this time.