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.

I had 
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 something special:

     * 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
     * replacement.

     * 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.