On Do, 2011-09-08 at 00:44 +0200, Lukas Zeller wrote:
On Aug 29, 2011, at 17:00 , Patrick Ohly wrote:
> I've written such a test and found some problems:
> 1. compile issue
> 2. TPluginApiDS::apiAddItem() treated DB_DataMerged as a failure
> and didn't return the local ID to
> TCustomImplDS::implProcessItem(), which caused a segfault later
> on (local ID NULL)
> Patches attached.
> But now I still see an unexpected Replace command.
I looked up what's happening in the code and the replace is not unexpected to me:
Status 207 is meant to indicate that the backend has added the item,
but in the process merged the add with some additional data (from an
external source, or another item in the sync set). So...
What the backend really did was replace its own data entirely with the
data sent to it, with no merging involved at all. Therefore sending back
that same data is unnecessary and could be avoided.
What we would need is another status "replaced existing item". Either
that, or allow the case that an Add returns 200 with a LUID that was
already in use before. The explicit status for it might be easier to
check for the engine.
No, that's the server updating the client with the result of the
Why would you expect this to be suppressed? On the contrary, this replace is explicitly
forced by the 207 status handling code.
With your explanation it makes sense.
Maybe we can sort out why you were expecting something else, before I
implement the "other half"
With that "other half" implemented the redundant update can be avoided,
because the backend would stop using the 207 status and the engine can
determine itself whether the merged item needs to be sent back.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.