Migrate DB schema of NotificationFilterPreferences

Development
,
1

Hi everyone,

I opened few months ago a brainstorming for changing the DB schema of NotificationFilterPreferences, I’m coming back on the subject to vote for performing the following changes on the DB schema:

  1. The columns user, pageOnly, page and wiki are removed and replaced by 2 columns: scope and entity. entity is a serialization of a reference so it’s typed as string in the schema. scope is strongly typed thanks to a given java Enum and its values can be: USER, PAGE, SPACE or WIKI.

  2. The columns emailEnabled and alertEnabled have been removed in favor in the schema of a set of NotificationFormats which is a java enum defining the available formats (Alert or Email for now): it means that a new table notification_filter_prefs_formats is used containing only the format and using the ID of the filter as index.

  3. The column allEventTypes which was of type text in the schema has been removed in favor of a set of String: it means that a new table notification_filter_prefs_eventTypes is used containing only one event type per row, and using the filter as index. Note that this solution allows to fix Loading... without needing a specific schema for Oracle.

  4. The column active has been removed without providing any replacement as the data is now useless and the related API are deprecated (see also: Loading...)

Note that you can already see the modifed schema in my draft PR: WIP: Migrate notification filter preferences to use another DB schema by surli · Pull Request #3154 · xwiki/xwiki-platform · GitHub

The goal of those changes is to allow better maintainability of the filters on the long run by allowing to create new formats / new scopes without needing a migration, and to keep as much as possible typing: for event types it’s not possible to have stronger type than String since that’s the only info we have (it’s the hint of the components).

This vote is only about changing the DB schema: it implies that we will have a migration to keep all data working with the new schema, except for the active data information which will be lost (but it’s a useless data). Those changes are targeting 16.6.0RC1 only.

I’m opening this vote for 1 week, so until friday 14th.

Here’s my +1.

2

I hope nobody is directly manipulating this table but +1 for the general logic.

Commented a few details of the new table on the pull request.