[Kde-pim] Akonadi attribute updates not working as expected
Volker Krause
vkrause at kde.org
Sun Oct 30 17:38:40 GMT 2011
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/
More information about the kde-pim
mailing list