docs: notification database schema

[johnhooks]

What?

Redesigns the database schema in markdown.

Why?

Improve the notification system to be fast and flexible.

• Add channels and subscriptions.
• Use a join table to provide a many-to-many relationships between messages and users.
• Use a join table to manage user channel subscriptions.

Continues Discussion #114

Issues with the previous schema

• Looking up messages by recipient, which could be either a role or users email, limits the system to messages targeting only a single user or a role. If more possibilities are added, it will only continue to complicate the query to find a users messages and enlarge the database index. The more flexible the system the slower it becomes.
• In the new system the logic and database queries to determine who should receive a message is done once, when the message is emitted, not on every query for a user's notifications.
• There is no mechanism to change the status of a single users message if the recipient is a role. Toggling the status would change the state of the notification for every user of that role. To maintain a status of every user in a single table would require duplicating the message for every user.

How?

This PR does not implement the schema, it is for documentation and planning.

[johnhooks]

Some ideas for core WordPress channels

• For each role, Admin, Editor etc.

  Alert only the Admins of out of date plugins.

• For post actions

  Could be used to alert users of modifications or a request to review a post or page. This could create a helpful history.

The final message render could be hookable, and filters applied to it. This would provide the hook function with the data about the user and the notification, allowing personalized messages.

[johnhooks]

The properties missing from the original, mostly because I didn't understand the translation aspect,

• recipient_key - I don't believe this is important in the new system of channels and subscriptions.
• sender_key - this is similar to channel source in the new system. It could be label sender_key if preferred. A channel also has a name_key.
• action_url - I can add this in, or it could be kept in the meta property. It's data that would never be queried against.

[johnhooks]

What should the character limit for the translation key columns be? Is there a character limit in WordPress that we can match?

[Sephsekla]

What should the character limit for the translation key columns be? Is there a character limit in WordPress that we can match?

Hmm I don't think this needs to be massive, since the message key is essentially namespaced by the sender key. I'll have a look at WP Core and see if something else does exist that would be helpful 🤔

[johnhooks]

@JasonTheAdams Does this look like a good start? I made it in MySQL Workbench. I looked at the option you linked in Slack, but it looked like it was only for paid subscription (I could be wrong, just didn't research further).

[johnhooks]

@Sephsekla it would be nice to have find some resolution to Issue #219 (even if the solution is a half measure to support implementing a functional API to experiment with). At the moment I haven't found a performant way to looking up the translations by key/slug.

Edit: To enable implementing features while we consider the translation system, we will store messages in the database in the translated language at time a notification is emitted. Though with a strong understanding it will need further consideration and most like require modifications.

[johnhooks]

This updated V2 schema makes adjustments based on Issue #209 and PR #251.

Notifications are to be translated at the time of emission and stored this way in the notifications table.

The subscription table is removed, in preference for in code channel registration and discovery. Subscriptions are linked to registered channels by the channel_name column, which is a key/slug/name (if anyone has a preference on how what to call this, please advise, this is simular in concept to block type name).

Considerations

• 32 characters might be two little for the channel name, especially considering it will be namespaced by a plugin slug. It will need to be indexed in the subscriptions table.
• TINYTEXT has a limit of 255 characters, does this seem appropriate for notification title and message? One concern I have is in regard to unicode characters and if the space requirements aren't considered, translations could be cut off if/when using more bytes than the original.
• Would it be common to query notifications by channel_name? Probably. Should it be indexed?

[erikyo]

LGTM!