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

[David Jarvie]

On Monday 25 October 2010 20:25:53 Kevin Krammer wrote:
> 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.

Thanks, Kevin - that helps a lot. So the problem is that the resource updates the item after it is created, to give it a remote ID, but the EntityTreeModel doesn't seem to know about this until after the ItemModifyJob is called, even though the ItemModifyJob doesn't actually execute until after the remote ID update is complete. Perhaps the ItemModifyJob is scheduled before completion of the other update?

Am I right in assuming that the resource currently has no control over whether the revision is updated when it allocates a remote ID? It calls the changeCommitted() method which calls the extra ItemModifyJob, so the revision increment seems to be automatic.

Cheers,
-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101025/2280468d/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/