[Kde-pim] Akonadi Question when removing items

[Daniel Vrátil]

On Tuesday 25 of March 2014 19:10:13 Martin Koller wrote:
> On Tuesday 25 March 2014 08:23:38 Kevin Krammer wrote:
> > On Monday, 2014-03-24, 19:33:28, Martin Koller wrote:
> > > On Monday 24 March 2014 09:29:05 Daniel Vrátil wrote:
> > > > On Sunday 23 of March 2014 20:32:08 Martin Koller wrote:
> > > > > Is it possible and correct that if I remove 2 mail items (local
> > > > > mbox, I
> > > > > select two mails and press Shift-Del) that the mbox resource gets
> > > > > the
> > > > > "itemRemoved()" call for the first item, but at this point in time
> > > > > the
> > > > > second items is already no longer in the Akonadi DB ?
> > > > 
> > > > Item removal notification is emitted after the item has been removed
> > > > from
> > > > Akonadi database. So it's like you say above, except for that even
> > > > when
> > > > the
> > > > first notification is delivered, the item is no longer in Akonadi.
> > > > 
> > > > > Or more general question: When a client (e.g. kmail) removes an
> > > > > item, is
> > > > > it
> > > > > the client who initiates the final removal of the entry in the
> > > > > Akonadi-DB
> > > > > and the (mbox) resource is just notified about that or does the
> > > > > client
> > > > > just
> > > > > send a request for removal and the (mbox) resource has to handle
> > > > > this ?
> > > > 
> > > > As Kevin  already explained, it's always the client (which can mean an
> > > > agent too in this case) who performs the item change and owning
> > > > resource
> > > > just writes the change into it's storage.
> > > > 
> > > > > (I fear it's the first as that is what I see happening)
> > > > 
> > > > Why fear? :-)  It's a perfectly fine behavior, because the resource
> > > > will
> > > > still receive RID, which should be all the resource needs to remove
> > > > the
> > > > item from it's storage backend.
> > > 
> > > Because in the mbox resource, the remoteId is depending on other
> > > remoteIds
> > > because it contains the position inside the mbox file.
> > > That means itemRemoved() is called, mbox needs to remove the item from
> > > the
> > > backend and must change all other remoteIds below it, which means:
> > > fetching their ids and changing, but while fetching, other items may
> > > already be gone from the akonadi db ...
> > 
> > Well, it only needs to do that when compacting the mbox, until then all
> > remote ids are still valid.
> 
> yes, of course. and that is the situation I have.
> I have an mbox, set to compact every 1 msg. Having 5 messages in the box,
> select first 2 msg, hit "Shift-Del" in kmail.
> mbox resource gets itemRemoved(), which leads to mbox::purge() which needs
> to change all remoteids below. FetchJob however only returns 3 as the second
> is already gone.

Your problem could partially be solved by porting the resource to 
AgentBase::ObserverV3 so that change notifications are delivered in batches. 
This would allow you to do compaction after each batch instead of every single 
change.

Although change notifications are compressed on the server and on the client 
side, it still does not guarantee that two subsequent batches are not 
generated.

Delaying the compaction by couple seconds after last batch should cover most 
cases however.

> > I think in the Mixedmaildir resource I handle that via remote revision,
> > e.g. knowing which item carries which version of remote ids.

Unless you store some mapping between last couple of generations of remoteIDs, 
this will not help, because the Item with "old" remote ID is already in 
Monitor's pipeline, so you can't modify it. In general, you can't modify 
already removed items.

> > 
> > CompactStoreJob and related code IIRC.
> 
> OMG ... EntityCompactChangeAttribute  ... WTH ...???
> 
> Can you explain the concept in that resource w.r.t. compaction, please ?

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140326/14c2ab80/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/