Get rid of eventstream.uselocalstore and eventstream.usemainstore configurations

Development
,
#1

Hi everyone,

continuing my work on notifications I recently stumbled across the two properties defined in xwiki.properties: eventstream.uselocalstore and eventstream.usemainstore.

Those properties used to have 2 usages: they were used for the storage of the events in the DB, and they were used for the storage of the notification filter preferences that are stored in the DB.

Since we moved the events in Solr, and that we moved the post-filtering code to legacy, the properties are now only used for the storage of the notification filter preferences. So the documentation we currently have in xwiki.properties right now is wrong and outdated since it’s talking about the events.

Now the default for those properties is to rely on the mainStore (both properties are set to true, but mainStore has priorities over localStore). Main store means main wiki here. So the side effect is that right now all notification filter preferences are stored in the main wiki by default, instead of being stored in the same DB than the users: it’s not very consistent and it might even lead to problems in case of manual operations on the DB.

So my proposal here is:

  1. Remove those properties from xwiki.properties and move the related code using them to legacy
  2. Change the default about storage of notification filter preference to use the local store, and introduce a migration to move filters of existing installations to the right DB. Also
  3. Introduce a new fallback property (not documented in xwiki.properties, but only in the RN migration notes) to change the storage of notification filter preferences for backward compatibility (if really someones want to keep the old behaviour)

I’m honestly not 100% sure 3. is needed but it feels safer.

wdyt?

#2

+1 for the removal.

Isn’t point 3 covered by point 1? I mean, the legacy code will look for the eventstream.uselocalstore and eventstream.usemainstore. So, anybody who wants to keep using them for some reason just have to depend on the legacy module afaiu?

#3

+1

Same here, I don’t quite understand point 3. To me, you are changing the default of those properties, but they still work, don’t they ?

Or do you mean that preferences should have their own, separate setup now ? It would indeed probably be safer to not change the default behavior regarding old events storage.

#4

So, by changing the default with 2 I will break the backward compatibility of those properties if somebody keep using the legacy store for events. In order to avoid I was thinking of not changing the default of those properties, but instead to completely use a different property for the notification filter preference in new code. And that new property would have a default to local storage and won’t be documented in xwiki.properties.

#5

Hi everyone,

I’d like to revive this proposal. As part of my work on Loading... I need to write a migration for cleaning up filters. It feels like it could be a good opportunity to also perform a move of the notification filters preferences if we agree that those should be stored by default in the same wiki as the users are stored.

so yes that’s what I meant

Now if I do the work for 3 I guess I could also put in xwiki.properties.