[Kde-pim] akonadiserver remembers collection context between fetch and delete

[Daniel Vrátil]

On Wednesday, June 24, 2015 06:29:28 PM David Faure wrote:
> From an akonadi resource, I do on startup:
> 
>   Akonadi::ItemFetchJob *job = new Akonadi::ItemFetchJob(collection1);
>   [...]
> 
> And much much later on, completely unrelated to that, when I want to handle
> deletion of an item in another collection (say collection2), I do :
> 
>   itemsRetrievedIncremental(Item::List(), deletedItems);
> 
> which leads to ItemSync doing an ItemDeleteJob(deletedItems).
> The thing is, these items have a remote ID, but no ID.
> I would have to run another job just to get the ID from the remote ID, that
> seems overkill. Especially since akonadiserver does support RID REMOVE :)

RID REMOVE is technically possible, but I'm not sure if supported...there's no 
way for you to select the base collection, because as you say below, 
CollectionSelectJob is private, and ItemDeleteJob only uses CSJ for 
collection-based removal of items.

> The problem: akonadiserver doesn't find the item from its RID, because it's
> still looking into collection1.
> 
> Remove::parseStream() starts with
> connection()->context()->collectionId() == collection1
> and doesn't change that in parseContext, since the command contains no
> collection context. So it queries for RID in collection1, and fails.
> 
> RID REMOVE ("f305c49b-5575-4130-821d-526e80a81596")
> NO No items found
> 
> Why does akonadiserver remember the initially listed collection as context?
> I suppose because of the stateful IMAP SELECT stuff? It seems inappropriate
> here...

We don't do SELECT anymore for FETCH, but send the "context" as part of the 
FETCH command. Historically ItemFetchJob did not "unselect" the folder after 
finishing, so that's why the FETCH handler does not unset the context either 
now.

I really don't like this stateful SELECT (exactly for this reason), sending 
the collection and tag as "context" for the command is partial solution  and 
first step to drop SELECT completely in the long term. I however did not want 
to change behaviour in KDE 4, so the statefulness of the context change 
remained (at least for collections, tag context is reset after every command).

> What can I do to work around this? I see a CollectionSelectJob in
> kdepimlibs/akonadi but it's deprecated and not installed anymore -
> understandably, since this statefulness is what's giving me trouble in the
> first place.

It appears that CollectionSelectJob has been private header since 2009. My 
understanding is that RID-based selection was intended to be used only by 
Resource internals which have access to the private header...

> Should ItemDeleteJob pass along the collection of the item, rather than just
> the remote id? Or is that not supported by the imap RID REMOVE syntax? (I
> see ProtocolHelper::commandContextToByteArray takes a collection, but for
> ItemDeleteJob, that seems to mean "delete this entire collection", right?)

I think the proper fix is to do the SELECT at the beginning of ItemSync. 
ItemSync is always per-collection and the collection is known beforehand, so 
ItemSync should ensure the Session context is set up correctly.

> Unless I'm missing something, I guess my only solution is to find out the
> actual id() of the items :(

Without the fix above, the FETCH to resolve IDs is your only option.

Dan

> PS: this is with Qt4, akonadi 1.13, I'm targetting 70 Qt4/kde4 users, can't
> use Qt5/KF5 yet for this.

-- 
Daniel Vrátil
Email: dvratil at kde.org
Jabber: dan.vratil at kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
_______________________________________________
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/