On Fri, 2012-07-13 at 21:39 +0200, Ove Kåven wrote: > 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.)
But these aren't changes which need to be sent back (which ITEM_MERGED is meant to request form the engine). > 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? The old "updated" boolean flag matches the new ITEM_REPLACED. It was meant to tell the engine that instead of adding a new item, an existing one was updated. But the semantic of that was too coarse (is the result different enough to be sent back?), thus the new enum. > > 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? ITEM_OKAY if add or update worked as requested, ITEM_REPLACED if the engine asks for adding the item (luid empty) and the incoming item has a UID/RECURRENCE-ID property which matches an existing item, in which case the backend has to turn the "add" into an "update" to avoid UID/RECURRENCE-ID conflicts. -- 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 SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
