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
>> > 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
> 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
"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,
> 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
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.