[Kde-pim] Akonadi Question when removing items

[Martin Koller]

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.

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

OMG ... EntityCompactChangeAttribute  ... WTH ...???

Can you explain the concept in that resource w.r.t. compaction, please ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
_______________________________________________
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/