Incubator » CB Activity

Query performance improved sufficiently in 4.2.0 and 4.2.1 making this no longer necessary. Global asset usage also improved in order to send notifications without replication.

Re-opening as this still makes sense from a storage perspective. If a notification is sent to a users connections then it could be 1000+ notifications replicated. In reality it should be 1 notification with 1000+ relationships. The relationships should be simple 2-4 column table usages as described in the original post to determine who receives the notification.

Relationships are likely only needed for notifications and conversations (to allow for group conversations). Activity and Comment streams don't need them as they don't work via replication (they work via asset).

This likely means removal of the user column for notifications. Then if all relationships are deleted we delete the notification row. This also means individual users can actually delete a notification instead of only hiding it.

Also the read state no longer needs to be a special table that's oddly notification asset specific. This can just be a part of the relationship. Example as follows.

user_id | type | item | read

Read: 42 | notification | 32 | 1
Unread: 42 | notification | 32 | 0

Note we don't need a primary id key in this case. Should load by user id, type, item and be unique index.

Allows read state to be per notification instead of blanket marketing all notifications as read by simply viewing notifications, which will be important for Conversations usage.

See #8457 for better proposal.