On Fri, 2012-07-13 at 18:59 +0200, Ove Kåven wrote:
On 07/13/2012 02:00 PM, Patrick Ohly wrote:
> I changed the backend API in the 1.2.99.x releases, and it seems that
> this (or attempts to adapt the code) broke the backend. In a nutshell,
> KCalExtendedSource::insertItem() should return an InsertItemResult with
> ITEM_OKAY if it was asked to replace an item and did so. Currently it
> seems to return ITEM_MERGED.
> I've probably let down Ove here by not updating the backend code while I
> made the API change :-/
Nah, I was aware you didn't care much about that backend anymore.
I still care, but I can't test it myself and thus rely on your help.
noticed the change because it wouldn't compile anymore if I didn't
change it, so I had updated it so that it returned ITEM_MERGED or
ITEM_OKAY, depending on whether the incoming UID already existed in the
database or not (i.e., which branch of that "if (oldUID.empty())" is taken).
That matches my theory. It should return ITEM_OKAY unless it does
* item added or updated as requested
* When a backend is asked to add an item and recognizes
* that the item matches an already existing item, it may
* replace that item instead of creating a duplicate. In this
* case it must return ITEM_REPLACED and set the luid/revision
* of that updated item.
* This can happen when such an item was added concurrently to
* the running sync or, more likely, was reported as new by
* the backend and the engine failed to find the match because
* it doesn't know about some special semantic, like iCalendar
* 2.0 UID).
* Note that depending on the age of the items, the older data
* will replace the more recent one when always using item
* Same as ITEM_REPLACED, except that the backend did some
* modifications to the data that was sent to it before
* storing it, like merging it with the existing item. The
* engine will treat the updated item as modified and send
* back the update to the peer as soon as possible. In server
* mode that will be in the same sync session, in a client in
* the next session (client cannot send changes after having
* received data from the server).
* As before, a match against an existing item was detected.
* By returning this state and the luid of the matched item
* (revision not needed) the engine is instructed to do the
* necessary data comparison and merging itself. Useful when a
* backend can't do the necessary merging itself.
I need to check why ITEM_MERGED doesn't work. Either way, avoiding it
should solve the problem.
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.