[Kde-pim] Akonadi attribute updates not working as expected

[David Jarvie]

On Sunday 06 November 2011 15:26:57 David Jarvie wrote:
> On Sunday 30 October 2011 19:16:01 David Jarvie wrote:
> > On Sunday 30 October 2011 17:38:40 Volker Krause wrote:
> > > On Saturday 29 October 2011 19:40:21 David Jarvie wrote:
> > > > After updating an attribute by CollectionModifyJob, a subsequent
> > > > CollectionFetchJob (called very soon afterwards) returns the old value of
> > > > the attribute, not the new one. The akonadiconsole debug output, which
> > > > seems to confirm this, is:
> > > > 
> > > > 24 HRID MODIFY ((-56
> > > > "file:///home/david/.kdetrunk/share/apps/kalarm/exp.ics") (0 "")) PARENT 0
> > > > REMOTEID "file:///home/david/.kdetrunk/share/apps/kalarm/exp.ics"
> > > > KAlarmCompatibility "2 0" 24 OK MODIFY done
> > > > 25 LSUB 261 0 () ()
> > > > * 261 0 (NAME "Old expired" MIMETYPE (application/x-vnd.kde.alarm.template
> > > > application/x-vnd.kde.alarm.active application/x-vnd.kde.alarm.archived
> > > > application/x-vnd.kde.alarm) REMOTEID
> > > > "file:///home/david/.kdetrunk/share/apps/kalarm/exp.ics" REMOTEREVISION ""
> > > > RESOURCE "akonadi_kalarm_resource_359" CACHEPOLICY (INHERIT true INTERVAL
> > > > -1 CACHETIMEOUT -1 SYNCONDEMAND false LOCALPARTS (ALL)) ENTITYDISPLAY
> > > > "(\"Old expired\" \"kalarm\" \"\" ())" AccessRights "wcdW"
> > > > KAlarmCompatibility "4 10910" KAlarmCollection "2 2 0 0") 25 OK List
> > > > completed
> > > > 
> > > > The value set for KAlarmCompatibility attribute in the first command, "2 0",
> > > > is not the value returned by the next command. This seems to be wrong
> > > > behaviour - is there some explanation for this?
> > > 
> > > It is the wrong behavior, and you seem to be very good at finding such issues 
> > > ;-)

I've found the reason for the attribute not being updated in the database. It turns out that the resource is updating the value of one attribute at the same time as the KAlarm application is updating the value of another attribute. The application update finishes later, and overwrites the resource's update.

The difference in the two CollectionModifyJob setups is that the application supplies as a parameter the Collection as refreshed from the database (i.e. including all its attributes), whereas the resource supplies a Collection which has been initialised with its remote ID, and with only the attribute to be changed having been added.

A way to get round this is for the application to create a new instance of Collection, initialise it with the collection ID, and only set up the attribute to be updated before calling CollectionModifyJob. However, this won't prevent other users of the KAlarm resource (e.g. plasmoids) from accidentally overwriting the resource-maintained attribute in a similar way.

What is really needed is for the resource to be able to prevent any application from ever updating one of the attributes, since this attribute is solely maintained by the resource. Is there any way to do this? If not, I think this is a facility which should be added, to enable resources to prevent clashes like this.

-- 
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: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111114/8ea4c969/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/