Changes for page Notifications Optimization

Summary

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

Details

Page properties

Content

...	...	@@ -30,11 +30,15 @@
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	+== Solution 1 - A: Add a timeout to the query ==
	34	+
	35	+To avoid an infinite loop
	36	+
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.
36	36
37		-== Solution 2-A: Create a memory cache ==
	41	+== Solution 2 - A: Create a memory cache ==
38	38
39	39	For each user, we could have a cache that store all the notifications that were returned during the last execution. This would be cleared:
40	40
...	...	@@ -42,11 +42,11 @@
42	42	* after a certain period of time
43	43
44	44	(((
45		-== Solution 2-B: Create an "evolving" memory cache ==
	49	+== Solution 2 - B: Create an "evolving" memory cache ==
46	46
47	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	48
49		-== Solution 2-C: Store in a permanent storage the notifications for each user ==
	53	+== Solution 2 - C: Store in a permanent storage the notifications for each user ==
50	50
51	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	52
...	...	@@ -69,9 +69,17 @@
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.
	76	+* 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.
	77	+* "Event Status" are generated for users who never goes to the wikis, which is a waste of resource.
	78	+* The "Event Status" table should probably be cleaned regularly to avoid having too much data, meaning some precious notifications could be lost while a user is absent (like a 2 weeks holidays).
	79	+* 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.
	80	+
	81	+(((
	82	+
72	72	)))
73	73	)))
74	74	)))
	86	+)))
75	75
76	76
77	77	\\