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

Summary

Details

Page properties
Content
... ... @@ -30,6 +30,8 @@
30 30  D. The same event is stored multiple times in the database, so it continuously fill the same CompositeEvent.
31 31  E. There is a bug in the recursion so the database always return the same results (but it would mean we have an infinite loop, so it would crash).
32 32  
33 +== ==
34 +
33 33  = Problem 2: Notifications are computed each time a page is loaded =
34 34  
35 35  There is absolutely no cache mechanism. So, even if the query to fetch the notifications is long, it will be re-executed the next time a user loads a page.
... ... @@ -69,9 +69,16 @@
69 69  Cons:
70 70  
71 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.
74 +* Since the filters need to be computed for each individual user, this process can take a lot of time, and it must be performed asynchronously.
75 +* "Event Status" are generated for users who never goes to the wikis, which is a waste of resource.
76 +* This mechanism cannot be applied for the Notifications Macro (that was designed to replace the Activity Stream), so it means both mechanism should co-exists.
77 +
78 +(((
79 +
72 72  )))
73 73  )))
74 74  )))
83 +)))
75 75  
76 76  
77 77  \\

Get Connected