[Kde-pim] Akonadi Question when removing items

[Kevin Krammer]

On Tuesday, 2014-03-25, 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.
> 
> > 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 ?

That attribute is not relevant for you use case, it is required for the 
communication between the resource's code and the file store abstraction.

The main class is the CompactChangeHelper. It keeps a mapping of remote Ids be 
revision.
Basically every time an mbox gets compacted and results in remoteId changes, 
the collection's remote revision is increased.

The helper keeps a mapping of remote Ids per revision, so it can provide the 
current remote id even if the item coming in has one from a prior revision.

The purge is done in mixedmaildirstore.cpp, line 2217 and beyond.
EntityCompactChangeAttribute is used to attach the "change" data, i.e. the new 
remote id for items and the new remote revision for the collection.

Since the mbox resource has direct access to the MBox instance it doesn't need 
that level of indirection. It could fill its variant of the change helper 
directly.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140410/77f38727/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/