Support/Notifications: Difference between revisions

Fixed formatting of Iteration 3 and noted it ensures some ref integ.
(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 18: Line 15:
# 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 72: Line 41:




== 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. Maintains referential integrity of object and content type. ==
watches
watches:
id content_type object_id event_type        user/email/whatever
id content_type object_id event_type        user/email/whatever
1  15          2345      UntranslatedEvent
1  15          2345      UntranslatedEvent


watch_elements:
watch_elements:
watch_id name        value (int for size/speed/ad hoc joins)
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        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        localizable 1
1        approved    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 107: Line 76:
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 =
Confirmed users
574

edits