Re: [SyncEvolution] UID matching during add<->add conflict

On Aug 16, 2011, at 12:54 , Patrick Ohly wrote: >> All but the first bullet point are not implemented so far. > > I had to resolve the double negation before this sentence made sense to > me ;-) So the "read back" bullet item is implemented, the rest isn't. Correct! That was a case of too many edits ;-) With the patch below the entire list (plus also handling not just add<->add conflicts) is implemented (but not yet tested).

>> However, actually detecting and merging a duplicate belongs into the >> backend, as the search usually must extend beyond what the engine sees >> as "current sync set" (imagine a date-range filtered sync, and an >> invitation added on both sides which is to far in the future to be in >> the date range window. The candidate for a merge could not be found in >> the sync set!). > > Agreed. So what's missing right now is a simple way to actually do the merge in the backend, without re-implementing half of libsynthesis. The (hopefully not so) longterm solution would be libvxxx. As a short term workaround, which is not exactly super elegant but not dangerous either, we could do the following: * we define another special return code for AddItem, say 419. The backend can return it when it detects that the added data SHOULD be merged with what the backend already has, but can't do that itself. * the engine would do the same things as (details see commit msg in the patch below) for 207 but additionally it would: * merge the incoming data with the data fetched from the backend with the localID returned from AddItem() * call UpdateItem() with the merge result in the backend Let me know what you think...