Merger
This page describes the details about the Merger/Demerger component. The Merger/Demerger is designed to solve issue of different capabilities between to different synchronization members. Different capabilities sets between different sync parties could lead to data loss, since unsupported "fields" can't get handled/stored if this isn't support by the synchronization member.
Different Capabilities Example
Capabilities of Member 1 consists of Field A, B and C. Capabilities of Member 2 consists of Field A, B.
Member 1 reports a new change with id 0001. The change entry (0001) contains Field A and C. Field A is set to 23, Field C is set to 42. The new change (0001) got transferred from Member 1 to Member 2. After, Member 2 changes recent commited entry 0001, Field A got set to 5. On next synchronization Member 2 reports entry 0001 as changed entry. Changed entry 0001 from Member 2 got transferred to Member 1. Booooom! Dataloss, Field C got now compeltely vanished. Since Member 2 couldn't handle/store Field C and changed entry 00001, which got transferred to Member 1 and replaced the entire entry 0001, with an entry which consists only of Field A (value = 5).
How does the Merger/Demerger solve this problem?
If the capabilities set of each Member is provided to the Merger/Demerger, the component is able to avoid this kind of dataloss. Before changed entry 0001 from Member 1 got transferred to Member 2, the entire got stored as XMLFormat into the Archive. Next all unsupported Field, like Filed C in this case, got "demerged" (which means stripped) from the entry. This modified entry, which is fully compatible to Member 2, got transferred to this Member.
When this entry got changed by Member 2, the OpenSync Engine checks the Archive for a copy of the entire entry, and mergers all unsupported Fields (only Fields which are not listed in the Capabilites of the Member!) to the change entry. In this example, Field C with value 42 got merged into the changed entry. After merging the entry got handed to the OpenSync Engine which does regular comparing and/or conflict handling if needed, and commits the changed entry to Member 1. The entry 0001 on Member contains of: Filed A 5 and Field C 42.
Implementation Details of the Merger
The Merger was implemented by Daniel Friedrich. The Merger relies on the specially designed XMLFormat. It also makes use of the Capabilities and Archive component. The Archive got used to store the original entire entry of the entry which have to be merged/demerged.
Features of the Merger
- Merging of entire XMLFields
