Confirmed users
574
edits
Support/Notifications: Difference between revisions
Jump to navigation
Jump to search
Undo revision 276151 by Erikrose (talk)
(Fixed formatting of Iteration 3 and noted it ensures some ref integ.) |
|||
| Line 4: | Line 4: | ||
= Use cases = | = Use cases = | ||
== Trigger a notification == | |||
# Notify anytime any Document changes. | # Notify anytime any Document changes. | ||
# Notify anytime a Document in a certain locale changes. | # Notify anytime a Document in a certain locale changes. | ||
| Line 15: | Line 18: | ||
# Anything Fred does | # Anything Fred does | ||
# Tell what the user is subscribed to | # Tell what the user is subscribed to | ||
# Notify any new thread in a given discussion forum | |||
# Notify any post (new thread or reply) in a given discussion forum | |||
# Notify any post in a discussion thread | |||
# Notify any new thread in any KB forum in a given locale | |||
# Notify any post in any KB forum in a given locale | |||
# Notify any new thread in a given KB forum | |||
# Notify any post in a given KB forum | |||
# Notify any post in a given KB forum thread | |||
# Notify on new question (confirmed) | |||
# Notify on new answer to a given question | |||
# Notify on answer marked as solution to a given question | |||
# Notify on new flagged item for review | |||
== Deliver notification == | |||
=== Logged in user === | |||
(non-exclusive) | |||
* To email | |||
* To private message | |||
* (Future, other options?) | |||
=== Anonymous user === | |||
* To email | |||
If a user registers, we should look for any anonymous watches with that email address and add them to the user, when the user is confirmed. | |||
= Evolution of table structure = | = Evolution of table structure = | ||
| Line 41: | Line 72: | ||
== Iteration 3: More normalization, yielding better queryability: orthogonality of path elements (not just hierarchy) is possible without ridiculously inefficient substring queries. I don't think the joins would be too bad, but benches would be nice | == Iteration 3: More normalization, yielding better queryability: orthogonality of path elements (not just hierarchy) is possible without ridiculously inefficient substring queries. I don't think the joins would be too bad, but benches would be nice. == | ||
watches | |||
id content_type object_id event_type user/email/whatever | |||
1 15 2345 UntranslatedEvent | |||
watch_elements: | |||
watch_id name value (int for size/speed/ad hoc joins) | |||
1 lang CRC32(de) # Postgres doesn't have a CRC32 function, so ad hoc joins on string keys would be a pain. | |||
1 localizable 1 | |||
1 approved 1 | |||
on UntranslatedEvent for object_id=2345 and content_type=15: | on UntranslatedEvent for object_id=2345 and content_type=15: | ||
| Line 76: | Line 107: | ||
This will bring it up to an (n+1)-table join, n being the max length of a certain event type's path *including* content type and object ID. | This will bring it up to an (n+1)-table join, n being the max length of a certain event type's path *including* content type and object ID. | ||
: Don't hamper work now because of Postgres. Assume we're on MySQL until Oracle shows up with a bill. | |||
= Features = | = Features = | ||