[Kde-pim] Re: Akonadi conflict problem - possibly EntityTreeModel issue?

[Kevin Krammer]

On Monday, 2010-10-25, David Jarvie wrote:
> I'm having difficulty working out why I'm getting a conflict when updating
> an Akonadi Item in KAlarm. It creates an item, and then updates it soon
> after. Then the conflict resolution dialog appears.
> 
> The sequence of events is to first call ItemCreateJob. That job's result
> slot returns an item with revision 0.
> 
> A short time after that, an ItemModifyJob is created.
> EntityTreeModel::data(ItemRole) is used to obtain the current revision
> number of the item being modified - the revision number returned is 0 -
> and that revision is used in the item supplied to the job.
> 
> The conflict resolution dialog seems to report that the revision number of
> the current item is in fact 1 - it shows revision numbers of 0 and 1 for
> the two conflicting items. AkonadiConsole also shows the items to have
> revision 1 while the conflict dialog is being displayed.
> 
> I'm fairly sure that KAlarm isn't doing any other updates on the item to
> cause the conflict, so I'm mystified as to why the conflict is occurring.
> It doesn't matter whether the ItemModifyJob is called directly or whether
> EntityTreeModel::setData() is used - the result is the same. I've tried
> looking at the debug log (attached) in AkonadiConsole, but don't
> understand it well enough to work out what's happening from it.
> 
> Any pointers to what might be happening would be very welcome.

Looking at the different sessions this is what happens in KAlarm's main 
session:

17 APPEND 90 0 (\MimeType[application/x-vnd.kde.alarm.active]) {634} 

KAlarm creates the item (Akonadi hands out item id 570 in its response):
17 [UIDNEXT 570

 then somewhen later it modifies it

18 UID STORE 570 REV 0 ( PLD:RFC822.SILENT {634} 

The item creation (tag 17) results in the item being added to the 
kalarm_active_resource (which retrieves it from Akonadi)

1304 UID FETCH 570 

The resource then hands out a remote id for the new item

1305 UID STORE 570

If we look for tag 1305 to see when this operation is finished, it is right 
before KAlarm tries to execute the modification with its tag 18.

Not sure what the correct way of handling this would be, maybe the revision 
shouldn' be changed when resources change remote id or remote revision.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101025/6f4df3a7/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/