peers had combined meaning, both being referenced by history for which
chat a message was in, and being reference by aliases for who authored a
message. This means that peers had conceptually different sub-groups:
all friends are both a chat and an author, but self is an author but not
a chat. With the addition of group chats this is amplified by groups
themselves being chats but not authors, and group members being authors
but not chats. Instead of having four sub-groups all within peers,
splitting peers into chats and authors gives a clean mapping,
simplifying interactions with the data.
In the new chats and authors tables, store what used to be a public_key
string as a BLOB, since it’s inherently a 32-byte binary value in both
cases. Call the public_key a UUID for chats, since group IDs are not
defined as public keys by toxcore.
Even though the data change is quite minor, the upgrade is large because
of SQLite's lack of support for modifying foreign key constrains for
existing tables. This means when peers are moved to new tables, all
tables referencing peers need to be cloned with a new foreign key
constraint, as well as all tables referencing those, recursively.
Files are conceptually temporary, having extra conflict handling logic
is unnecessary, and having the test fail to run if it crashed on last
invocation is annoying.
Replace underlength resume_file_id's with arbitrary data. Loaded file IDs are
not used for anything at this time, but they should not be null nor invalid.
Any 32-byte value is valid, so use all 0's for consistency.
Fix#6553
* Move free functions to the anonymous namespace
* Additionally move static free functions to the anonymous namespace
* Move functions that must be accessed externally to static class functions
Due to an old bug that has since be fixed, old history dbs can contain both a
Tox ID version and Tox public key version of the same friend, and always
themselves. They could have n more duplicates if they've updated their nospam.
Tox ID is an invalid length to be stored in strongly typed ToxPk, and in
general having multiple entries belonging to the same user effectively violates
our UNIQUE constraint on public_key.
Introduced in 7168d2b858Fix#6485
* Resolves#6221
* System message schema designed to take enum of message base + args
* New table layout required many updates to the queries executed by
history
* Bonus reduction of history signals/slots by issuing some file transfer
insertions directly when possible
* Added new negotiating friend state to allow delayed sending of offline
messages
* Added ability to flag currently outgoing message as broken in UI
* Reworked OfflineMsgEngine to support multiple receipt types
* Moved resending logic out of the OfflineMsgEngine
* Moved coordination of receipt and DispatchedMessageId into helper
class usable for both ExtensionReceiptNum and ReceiptNum
* Resending logic now has a failure case when the friend's extension
set is lower than the required extensions needed for the message
* When a user is known to be offline we do not allow use of any
extensions
* Added DB support for broken message reasons
* Added DB support to tie an faux_offline_pending message to a required
extension set
indexes need to be created after their corresponding table is created.
QMap doesn't enforce insertion order, just key order, so use a vector.
Also verify indexes from sql_master instead of only tables.
Before a bug in qTox would make it possible for a user to try to send an empty
action type message. This would fail to send at toxcore, but still be persisted
in history, causing it to fail every time FauxOfflineEngine tried to resend
it. Moving these stuck messages into the broke_messages table will stop qTox
from attempting to deliver them on each connect, and display in the GUI to
users that the messages aren't really pending anymore.
Fix#5776
Due to a long standing bug, faux offline message have been able to become stuck
going back years. Because of recent fixes to history loading, faux offline
messages will correctly all be sent on connection, but this causes an issue of
long stuck messages suddenly being delivered to a friend, out of context,
creating a confusing interaction. To work around this, this upgrade moves any
faux offline messages in a chat that are older than the last successfully
delivered message, indicating they were stuck, to a new table,
`broken_messages`, preventing them from ever being sent in the future.
This allows upgrade steps to query the db at the last version and run C++ code
on the results, then do a single transaction to make the upgrade, instead of
all actions of each upgrade step being required to be part of the overall
upgrade transaction.
