[Kde-pim] Modfiying collection from within Resource::retrieveItems ?

[Christian Mollekopf]

On Fri, Apr 10, 2015, at 09:49 AM, David Faure wrote:
> I'm doing some work on the SugarCRM akonadi resource.
> 
> To improve syncing collections so that it's incremental (listing only
> things that have changed since the last timestamp), I need to store that
> timestamp into the DB (so that it's persistent across restarts).
> 
> So at the end of the list job (triggered by retrieveItems()), I do
> 
>            // I reuse EntityAnnotationsAttribute because I'm too lazy to
>            inherit from Attribute and this seems like a nice generic
>            solution

I guess you can do that for the SugarCRM resource. The attribute is
somewhat IMAP specific originally,
but I don't think it will break anything.

>             EntityAnnotationsAttribute *annotationsAttribute =
>                     mCollection.attribute<EntityAnnotationsAttribute>(
>                     Akonadi::Collection::AddIfMissing );
>             if (!annotationsAttribute ||
>             annotationsAttribute->value(s_timeStampKey) !=
>             mHandler->latestTimestamp()) {
>                 annotationsAttribute->insert(s_timeStampKey,
>                 mHandler->latestTimestamp());
>                 mCollection.addAttribute(annotationsAttribute);
> 
>                 Akonadi::CollectionModifyJob *modJob = new
>                 Akonadi::CollectionModifyJob(mCollection, q);
>                 connect(modJob, SIGNAL(result(KJob*)), q,
>                 SLOT(onCollectionModifyDone(KJob*)));
> 
> The problem is that this job never runs, because retrieveItems() is run
> from some ItemSync job,
> which doesn't compile until itemsRetrievalDone() is called. So my modJob
> is queued up
> and both things are waiting for the other -> deadlock.
> 

In the imap resource we also do that, but we don't wait for the modify
job to finish.
We simply post collectionmodifyjob and then finish the item sync with
itemsRetrievalDone.

> How can I modify a collection, from within a resource? I'm confused by it
> being both a slave
> that implements jobs, and something that can actually create jobs (but
> such jobs do not call back
> into the resource, I assume?).
> 

Correct, changes done by a resource are not replayed to the same
resource.

> Should I simply move this code out of the internal job class, to put it
> after the itemsRetrievalDone() call,
> (from the above description it sounds obvious, but it breaks
> encapsulation a bit, in this resource's design)
> or is there a better way to do all this?
> 

I think you're not getting around this. I know it's not entirely pretty,
but I'm not aware of anything better.
_______________________________________________
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/