view .hgtags @ 2716:06160b529da6

core (memory/sqlite): changed history constraint /!\ Database schema change /!\ History was using a unique constraint on `profile_id, timestamp, source, dest, source_res, dest_res`, which can cause trouble because several messages send quickly by the same person can have a common timestamp (specially with delayed messages where precision is second), resulting in message loss. The new constraint use `profile_id, stanza_id, source, dest` where `stanza_id` is XEP-0359 stanza_id, so it's unique by definition, and no message should be lost anymore. Because sqlite doesn't support altering table with a constraint change, we have to create new tables and copy old data to new one, which can be pretty long. Sqlite update mechanism with "specifics" has been fixed when several updates are applied (e.g. moving from v5 to v7) and a specific is in the workflow.
author Goffi <goffi@goffi.org>
date Sun, 09 Dec 2018 14:07:26 +0100
parents 755a0b8643bd
children 202e2d8e3d7b
line wrap: on
line source

d660d1e5cee410bf9ac15b89ceb93543bcff0a6f 0.0.2
b95550704b4f965c9dca5f6681186bf8a9b64074 0.0.3
b778622b87337785252d47d2b3c4fe3085a37ab4 0.1.0
53aa958a2d3d6451ae75610e3c6fb947d3d6f21b 0.1.1
cc2afb92ab93a4c6399ca9b6cdc5224878a57a24 0.2.0
df6b9b881f0e9f335483c986b00fd58f2ed6164a 0.3.0
12cfa23c6ab9235dddb2e8887eb0fe90fc98da75 0.4.0
f93e917be3f41a254a4612da22ed9fc5e0209f80 0.4.1
a090e5ee83c2c2d9d110c7516c3d74573426a97b 0.5.0
008c8ccd5dcc4c47578ee7190e6823186720c864 0.5.1
21e6d11615eaeb7e03bacf4eb53e5c3c5d54ce08 0.6.0
b075c5a576ef3ce628e30b0ce02bf00ec35a3c4c 0.6.1
eecd84a2530aacb3255f702cdab2010b39bb1851 0.7.0a1
eecd84a2530aacb3255f702cdab2010b39bb1851 0.7.0a1
0000000000000000000000000000000000000000 0.7.0a1
0000000000000000000000000000000000000000 0.7.0a1
534b264d63df0e6241395b26cfd994b9fee187f0 0.7.0a1
b42aa52d262106ee6743d0205830be9d837ebfa9 0.7.0a2