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

[David Jarvie]

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 wish I didn't find these issues, but I suppose it's useful if they exist. ;-)
> 
> > 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
> 
> They are both for the same resource, which is inherited from SingleFileResource.
> 
> > - 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
> 
> I put a collectionChanged() method into the resource, but it isn't called after the CollectionModifyJob to update the attribute, and the database shows the attribute value to remain unchanged.
> 
> > - 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.
> 
> I can't manage to reproduce the sequence of events any more - the fetch isn't happening after the update - I have no idea why. However, the problem of the attribute value not being updated in the database remains.
> 
> A hint as to the reason may be shown from my investigations into another issue. When the read-only status of the resource is changed in the resource's configuration dialog, it doesn't result in the collection rights being changed in the database. There is no obvious reason why the KAlarmResource should behave in a different way from other SingleFileResource classes, which seem to work correctly.
> 
> I've been tracing what happens, and I found that retrieveCollections() is never called after accepting the config dialog - this is what should update the rights in the database. This in turn should be called as a result of the call to synchronizeCollectionTree() in SingleFileResourceBase::reloadFile(). However, although reloadFile() is definitely called, synchronizeCollectionTree() never runs - when ResourceScheduler::scheduleNext() is called to schedule it, mCurrentTask.type is not Invalid, so synchronizeCollectionTree() isn't scheduled and never runs.
> 
> I suspect, but have not yet established, that a call to ChangeReplay when the resource initialises may be responsible. This is called for KAlarmResource, but not for ICalResource (I don't know why there is a difference). It looks possible that ChangeReplay never signals completion, which could leave the scheduler queue stuck. I'm not sure yet how to check for completion of ChangeReplay, so I'm not sure about this.

Hi Volker,

Just wondering if you have managed to look at the failure to update the Akonadi database? Unfortunately, I can't fix these problems without that being fixed.

Thanks,
-- 
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/20111106/32e8fc78/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/