#369 and #370: Add support for the clear chat room history event #411
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The room ID differs from a room JID in the following way: when a room gets destroyed, and is recreated, it can be recreated using the same JID. The numeric identifier however, will be unique. The room ID can therefor be used to differentiate between data recorded for various 'reincarnations' of a room with the same name. The database update scripts will populate the room ID for existing rooms with the latest ID as recorded in the Openfire table `ofMucRoom`. This is not necessarily correct (as data recorded by the Monitoring plugin may relate to earlier versions of a room). This behavior does, however, reflect the current behavior of the Monitoring plugin, that currently always associates data with the 'latest' reincarnation of the room. Starting with this commit, new incarnations of the room will receive distinct IDs. This is a prerequisite for fixing issues igniterealtime#369 and igniterealtime#370.
Openfire 5.0.0 introduces a 'clear room history' event. In this commit, the monitoring plugin implements that event, by: - deleting associated database content - removing deleted content from the Lucene indices. Fixes igniterealtime#369 Fixes igniterealtime#370
|
I have not tested any of this yet, which is why I'm opening this PR in 'draft' status. |
|
The continuous integration will fail until API changes in Openfire are available through a published dependency. |
This prevents messages to be 'lost', as they're registered to a conversation that no longer gets processed. By properly ending the old conversation, new messages will cause a new conversation to be started.
|
I've tested the install and upgrade scripts for MySQL, HSQLDB and Postgres. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We can address both #369 and #370 by implementing the handling of the "clear chat history" event from Openfire. Openfire sends a "clear chat history" event in the following scenarios:
This intends to replace #408
The approach in this PR differs from the one in 408 in that it does not attempt to introduce a new unique identifier for a room. Instead, an Openfire-provided identifier (
roomID) is re-used. This intends to:Prior to the changes introduced here, the Monitoring plugin did not distinguish between different 'incarnations' of a room (a room can be deleted, then recreated with the same JID). With the changes in this PR, the plugin now does - but only for data that is recorded 'from now on'. This PR contains a database update script that explicitly relates all preexisting data to the last incarnation of a chat room (if one still exists). This isn't quite right, but it is not 'more wrong' than what was functionally going on prior to these changes.