|author||Guilhem Moulin <firstname.lastname@example.org>||2019-05-22 21:36:21 +0200|
|committer||Guilhem Moulin <email@example.com>||2019-05-27 00:07:30 +0200|
interimap: fix handling of mod-sequence values greater or equal than 2 << 63.
SQLite processes every INTEGER values as a 8-byte signed integer, so we need to manually do the conversion from/to uint64_t client-side if we don't want to overflow or receive floats. https://www.sqlite.org/datatype3.html#storage_classes_and_datatypes http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/ We could also do the same trick for local/remote UIDs, UIDVALITY and UIDNEXT values to slim the database down at the expense of pre/post- processing. (Values of SQLite's INTEGER class are 1, 2, 3, 4, 6, or 8 bytes signed integers depending on the manitudes, so we could save some space for values ≥2³¹.) But that seems a little overkill.
Diffstat (limited to 'Changelog')
1 files changed, 2 insertions, 0 deletions
@@ -40,6 +40,8 @@ interimap (0.5) upstream;
RFC 3501 sec. 6.3.4).
- interimap: SQLite were not enforcing foreign key constraints (setting
the 'foreign_keys' PRAGMA during a transaction is a documented no-op).
+ - interimap: fix handling of mod-sequence values greater or equal than
+ 2 << 63.
-- Guilhem Moulin <firstname.lastname@example.org> Fri, 10 May 2019 00:58:14 +0200