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.