Last modified by Vincent Massol on 2024/02/26 17:53

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

Summary

Details

Page properties
Content
... ... @@ -42,9 +42,22 @@
42 42  * after a certain period of time
43 43  
44 44  (((
45 -== Solution 2-B: Create an evolving memory cache ==
45 +== Solution 2-B: Create an "evolving" memory cache ==
46 46  
47 -Same than 2-A, but when a new event is triggered, the cache would not be cleared. Instead, it will be
47 +Same than 2-A, but when a new event is triggered, the cache would not be cleared. Instead, the new event will be considered for each user, and added the cache if the event is not filtered by the user preferences.
48 +
49 +== Solution 2-C: Store in a permanent storage the notifications for each user ==
50 +
51 +This title is not exactly what I meant. The idea is not to store each notification in a table (the event is already in the event stream store), but the "read" status of each event for each user, **when the event is recorded**.
52 +
53 +Concretely, this is how it would perform:
54 +
55 +1. An event is triggered in XWiki.
56 +1. The event is recorded in the Event Stream table.
57 +1. For each user, we compute either or not the event should be displayed, according to their preferences.
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
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.
48 48  )))
49 49  
50 50  

Get Connected