Bug 257544

Summary: Duplicate id values in db mode (mysql) on bidirectional replication
Product: [Applications] kmymoney Reporter: lazabt <lazabt>
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED NOT A BUG    
Severity: wishlist CC: fvilas, mfcarpino
Priority: NOR    
Version: 4.5   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description lazabt 2010-11-21 20:20:28 UTC
Version:           4.5 (using KDE 4.5.3) 
OS:                Linux

I'm trying to use KMyMoney in such a way:
There are two computers (A and B) with two standalone mysql databases controlled by KMM. A and B are in one LAN, databases set up to replicate on each other (DB@A->DB@B, DB@B->DB@A), and there's no database server always turned on. So when the computers are online, all changes doing in each copy of KMM DB replicate to another DB copy, DBs are in sync.
The problems start in the case described in "steps to reproduce": on step 3 we get replication conflict because DB@A and DB@B have records with the same IDs.
It's a known problem of replication with autoincrement IDs in general and it's generally solved by setting different offsets and step=2 (for two DBs) of autoincrement sequences on DB level. E.g.:
IDs of DB@A: offset=1 step=2 (id sequence: 1, 3, 5, 7, 9, ...)
IDs of DB@B: offset=2 step=2 (id sequence: 2, 4, 6, 8, 10, ...)
But KMM controls autoincrementing by itself (because of prefixed IDs and different storage formats I suppose) so the problem is here.
Could you please add the feature of setting up offset and step of IDs: to IDs generation logic and to user interface.

Reproducible: Always

Steps to Reproduce:
step 1. A is on, B is off, user adds a new transaction in KMM@A
step 2. A is off, B is on, user adds a new transaction in KMM@B
step 3. A is on, B is on, DBs tries to sync

Actual Results:  
Replication conflict

Expected Results:  
DBs at A and B are in sync
Comment 1 Fernando Vilas 2010-11-22 01:47:49 UTC
Definitely a wishlist item. This was suspected, but never addressed, since it was anticipated that KMM is a single user program and this particular error was envisioned to occur when 2 users are logged in simultaneously. As a temporary workaround, A and B could be synced as step 1a. This issue is not limited to MySQL, but would apply to all databases, and possibly even the XML backend.
Comment 2 Michael Carpino 2018-03-01 15:41:25 UTC
Enhancement requested over 5 years ago with an older version of KMM.  Bug closed.