[Kde-pim] fixing mbox - general Akonadi problem ?

[Daniel Vrátil]

On Wednesday 12 of February 2014 19:07:53 Martin Koller wrote:
> On Wednesday 12 February 2014 18:54:43 Daniel Vrátil wrote:
> > On Wednesday 12 of February 2014 18:22:40 Martin Koller wrote:
> > > On Wednesday 12 February 2014 17:41:26 Daniel Vrátil wrote:
> > > > When you delete a mail from MboxResource::itemRemoved() and there are
> > > > more
> > > > items waiting for deletion in ChangeRecorder's pipeline, it's
> > > > necessary to
> > > > modify RIDs of all emails affected by the compaction BEFORE
> > > > changeProcessed() is called. This should cause all other items pending
> > > > deletion in
> > > > ChangeRecorder's pipeline to be refetched from Akonadi with updated
> > > > RID.
> > > 
> > > I tried that but that still fails because I try to modify all other
> > > moved
> > > entries via the following code where I want to retrieve the other
> > > Akonadi
> > > Items via an ItemFetchJob but obviously during the exec() event loop, I
> > > just get the next call to MboxResource::itemRemoved() :-(
> > > 
> > > Is that completely wrong what I do here ?
> > > 
> > >     // change all remoteIds of the moved items (all items after the
> > >     deleted
> > > 
> > > one change their offset in the file)
> > > 
> > >   if ( !movedEntries.isEmpty() ) {
> > >   
> > >       qDebug() << "#movedEntries=" << movedEntries.count();
> > >       Item::List movedItems;
> > >       const QString colId = QString::number( mboxCollection.id() );
> > >       const QString colRid = mboxCollection.remoteId();
> > >       foreach (const KMBox::MBoxEntry::Pair &p, movedEntries) {
> > >       
> > >         Item movedItem;
> > 
> > If it's not too difficult (and slow) to extract Message-ID headers from
> > each message, you might want to use setGID() instead of setRemoteId().
> > The reason is that in the database the GID column has an index, while
> > remoteId column does not, so looking up the items based on GID will be
> > faster.
> 
> Thanks for your hints, but my main problem is: how can I avoid that the
> exec() call of the Job does not continue with the next
> MboxResource::itemRemoved() call ? Can I stop the ChangeRecorder somehow ?
> Is it simply a Qt disconnect() or how ?

Ah, sorry - I thought you fixed it by using the exec() call :-) It's weird 
though: next task queued in the change recorder is not dispatched until 
changeProcessed() is called. The FetchJob itself does not trigger 
changeProcessed, so there must be another problem.

This is a long shot, but it's the only thing I can think of ATM: Try setting 
fetchJob->fetchScope().setCacheOnly(true). When some item is not in cache 
during a fetch job, the server will ask the resource to fetch the item and 
push it to Akonadi The resource then has to call changeProcessed(), which 
could cause the next queued task to be dispatched. With cacheOnly set to true, 
Akonadi will never query the resource, preventing the unwanted 
changeProcessed() call.

If this does not help, I'll check the code tomorrow and try to figure out 
something.

Dan


-- 
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/20140212/d3f51f66/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/