Feature proposal #6658
closed
Implement separate notifications api
Added by krileon over 7 years ago.
Updated almost 7 years ago.
Description
High notification row test needs to be done in addition to a high read table row test. Try to improve the queries further for better performance. 100,000 row test currently performs at 50ms.
Split notifications into a new database table as it's causing activity table optimization problems. A new API should be made as well that'd just extend the Activity class. This likely means we can get rid of the read table and just make the read state a column for the notification (only the recipient can make it read).
Notification table should also extend the Activity table. For all intended purposes the Notifications should just be treated like Activity in nearly every way. So no new triggers specifically for notifications. The extensions to the Activity table are simply a "user" and "read" column. User determines the notification recipient and read determines if the recipient has read the notification. All the conditions against asset looking for notifications can simply be changed over to do an instanceof check for Notifications stream or NotificationTable as needed.
This should also work with the global asset to allow for global notifications.
- Priority changed from Normal to High
- Subject changed from Further optimize queries to Further optimize queries and implement separate notifications api
- Subject changed from Further optimize queries and implement separate notifications api to Implement separate notifications api
- Target version changed from 6.0.0 to 4.1.0
Removing the read table may not work for cases like global notifications since the read state would need to be per person. Conversations would basically need to be the same as well. So keep, but optimize further, the read table for keeping track of what notifications have been read.
- % Done changed from 0 to 60
- % Done changed from 60 to 80
Still needs global asset handling and XML params to adjust notifications behavior (e.g. paging).
- % Done changed from 80 to 90
This is more or less done. Just needs migration.
- Status changed from Assigned to Resolved
- % Done changed from 90 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF