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
*/
ITEM_OKAY,
/**
* 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.
*/
ITEM_REPLACED,
/**
* 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).
*/
ITEM_MERGED,
/**
* 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.
*/
ITEM_NEEDS_MERGE
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
