Database queries for metadata only returned it for messages that were delivered already.
However, there are cases (e.g. a pending message needs to be delivered) where
the validator needs to retrieve the metadata from the database.
For these cases, a special database query has been introduced.
This adds a new table to the database to hold message dependencies.
It introduces two more message states: pending and delivered
The valid column in the database was renamed to state to better reflect
its new extended meaning.
The DatabaseComponent was extended with three methods for:
* adding dependencies
* getting dependencies of a message
* getting messages that depend on a message (dependents)
* getting messages to be delivered (by startup hook)
* getting pending messages to be possibly delivered (by startup hook)
In order to reflect the new states, things that were previously true for
VALID messages have been changed to now be true for DELIVERED messages.
Since pending messages should not be available to clients, many database
queries have been modified to only return results for delivered
messages.
All added methods and changes should come with updated unit tests.
Please note that the database version was bumped in this commit.
The database's transaction lock is reentrant, meaning that a thread that's already holding the lock can acquire it again. This would allow a thread that already has a transaction in progress to start another transaction, which could cause transaction isolation issues and/or lock timeouts on the database's internal locks.
Check that the current thread isn't already holding the lock when starting a transaction.
Don't keep message status rows for groups that are invisible to the contact - this avoids the need to join the groupVisibilities table when selecting messages to offer or send. Add or remove status rows when group visibility changes.
Torsten Grote
akwizgran
Santiago Torres