Bug 257544 - Duplicate id values in db mode (mysql) on bidirectional replication
Summary: Duplicate id values in db mode (mysql) on bidirectional replication
Status: RESOLVED NOT A BUG
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.5
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-21 20:20 UTC by lazabt
Modified: 2018-03-01 15:41 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.