From version < 1.3 >
edited by Guillaume Delhumeau
on 2019/03/06 15:01
To version < 1.4 >
edited by Guillaume Delhumeau
on 2019/03/06 15:03
< >
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -56,9 +56,22 @@
56 56  1. The event is recorded in the Event Stream table.
57 57  1. For each user, we compute either or not the event should be displayed, according to their preferences.
58 58  11. If the event should be displayed for the user, create a line in the "Event Status" table for the user, with the "read" value to false.
59 -11. If the event should not be displayed for the user, it is simply dismissed
59 +11. If the event should not be displayed for the user, it is simply dismissed.
60 60  1. When the user fetch the notifications, there is no complex SQL query to perform anymore. We just need to look into the "Event Status" table which events are linked to the current user id.
61 +
62 +(((
63 +Pros:
64 +
65 +* No need for SQL injections, resulting in a complex SQL query, that can be buggy.
66 +* Even if the notifications are fetched every time a page is loaded, it is not very costly (the "Event Status" table acts like a cache).
67 +
68 +(((
69 +Cons:
70 +
71 +* On a wiki with a very large number of users, it means we would need to write a lot of lines in the "Event Status" table every time an event is triggered.
61 61  )))
73 +)))
74 +)))
62 62  
63 63  
64 64  \\

Get Connected