Changes for page Notifications Optimization

Summary

• Page properties (1 modified, 0 added, 0 removed)

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	\\