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? _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
