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

[Volker Krause]

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 don't have an explanation for this yet, collection attribute changes seem to 
work fine in general here (if not it would badly mess up IMAP and Maildir for 
example). So, this likely depends on more context than just the commands you 
posted.

Some ideas:
- the log does not show these are the same collections (HRID vs. UID 
addressing), unlikely but better verify in the db that there is only one of 
them
- is there a change notification emitted for the modification? if not this 
would indicate that the change in attribute values was not recognized and thus 
the change was not committed to the db
- does the fetch happen in the same session? if not, the transaction of the 
session writing the change might not have been committed yet and the other 
side might not see it yet.

regards
Volker
-------------- 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/20111030/e5bb0bbb/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/