Closed auxibee closed 6 months ago
Thanks for this. Some comments:
entity_id
only captures the entity's id. But we can't tell what entity that is.What about making it modular by separating the type of notifications ? We have have a different table for each type of notifications like comments notifications, post notification, community notifications etc. In this case each notification table will store its actor id and the comment/post /etc id We will fetch from notification subscribers and join all the notification tables.
What benefits do we get from doing it like this?
i was confused with how we will fetch the post/comment/etc of the notification with the initial approach and hence this new suggestion.
You need to update the issue with the new fields, etc.
Schema design
Notification {
id
message
actor_id
entity_id
entity_type
dateCreated
}
NotificationSuscribers{
id
notification_id
user_id
read
}
Completed with #64
A non-realtime notification system for Compa.
Features
Implementation
Notifications are events that happen we would like to inform users about such as comment added, comment deleted, a new feature added etc.
We will have a table to capture the different kinds of events that occur in our system. For now only comment added event will be added
A notification table which will capture the main notification message, actor_id-optional(the user performing the event) and entity id-optional(being link to a particular post, comment etc). Some notifications will just be a message hence the actor id and entity id being optional
Notification subscribers table(many to many) will capture users and their notifications
User story for Comment Added Event
user adds comment to a post get all users who have comments on the post including the original poster Notification - username has added a comment on post_title