Use 64-bit IDs for messages
authorMichael Marley <michael@michaelmarley.com>
Fri, 9 Mar 2018 17:17:05 +0000 (12:17 -0500)
committerManuel Nickschas <sputnick@quassel-irc.org>
Wed, 23 May 2018 22:33:28 +0000 (00:33 +0200)
commit6a835281b265df6a06b7f41109ad2d449899fed0
tree52a41b148c1f46405a8da327503e58326a06c62e
parent79aa3994d78860c0b7a623a46ce44dffff988fd9
Use 64-bit IDs for messages

Increase the length of message IDs from 32 to 64 bits, allowing for
many more total messages be stored.  Because messages are synced to
the client, this requires a protocol change.  The protocol change is
guarded behind a new feature flag that will retain backwards
compatibility with existing clients, at least until the IDs go above
the maximum for a 32-bit number.  At this point, legacy clients will
behave incorrectly or perhaps crash, but this is an acceptable risk
because in the current implementation, this event would cause the
core to behave incorrectly or crash.  The client is also still
limited to 32 bits worth of backlog per buffer displayed at once
(due to Qt limitations), but it would be highly unlikely to hit
this limit because the client becomes unusably slow with a small
fraction of that amount of backlog loaded in a single buffer.

For SQLite, no schema change was necessary as SQLite makes no
differentiation between the bitnesses of integers.

For PostgreSQL, this patch also changes senderId to 64-bit, but
this has no effect outside the PostgreSQL database driver.

This patch only changes the message ID to 64-bit.  All other IDs
are left at 32 bits because it is either exceedingly unlikely or
technically infeasible to have more than 32 bits worth of entries
in any of the other tables.  If, at some point, it is decided that
other IDs should also be 64-bit, the way in which the feature flag
affects (de)serialization will need to be changed.  This is because
the flag LongMessageId currently acts upon all IDs inheriting from
SignedId64 and it would be necessary to independently control the
(de)serialization of each ID if other IDs became 64-bit in order to
continue to maintain backwards compatibility.  One possible method
of doing this would be to subclass the SignedId64 class for each
ID that inherits from it to allow for separately controlling
(de)serialization for each of the types.  I have not implemented
this, however, because of the unlikelihood of any of the other IDs
ever being made 64-bit.

Closes GH-343.
18 files changed:
src/common/CMakeLists.txt
src/common/quassel.h
src/common/types.cpp [new file with mode: 0644]
src/common/types.h
src/core/SQL/PostgreSQL/setup_010_sender.sql
src/core/SQL/PostgreSQL/setup_050_buffer.sql
src/core/SQL/PostgreSQL/setup_060_backlog.sql
src/core/SQL/PostgreSQL/version/29/upgrade_010_alter_sender_64bit_ids.sql [new file with mode: 0644]
src/core/SQL/PostgreSQL/version/29/upgrade_050_alter_buffer_64bit_ids.sql [new file with mode: 0644]
src/core/SQL/PostgreSQL/version/29/upgrade_060_alter_backlog_64bit_ids.sql [new file with mode: 0644]
src/core/abstractsqlstorage.h
src/core/coresession.cpp
src/core/postgresqlstorage.cpp
src/core/sql.qrc
src/core/sqlitestorage.cpp
src/core/sqlitestorage.h
src/qtui/chatitem.cpp
src/qtui/debugmessagemodelfilter.cpp