Re: [SyncEvolution] Nokia N9 syncevo-to-syncevo weirdness
Den 13. juli 2012 20:52, skrev Patrick Ohly:
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:
Well, from what I can tell, the code does something special. (It seems
to be merging something between the old and new objects - apparently the
ids and the "created" property, at least.)
Also, the old code set "updated = false" if oldUID was empty, and
"updated = true" if it was not, and it was my assumption that the
distinction was significant and should still be returned as different
cases - especially since the new enum type ought to be more expressive
than the old boolean, not less?
I need to check why ITEM_MERGED doesn't work. Either way,
avoiding it
should solve the problem.
What is it supposed to do instead?