[Kde-pim] Reload collection from server?

Christian Mollekopf chrigi_1 at fastmail.fm
Sun May 31 10:37:55 BST 2015


On Sat, May 30, 2015, at 10:02 AM, David Faure wrote:
> Is there some API in kdepimlibs/akonadi for telling a resource to discard
> all of a collection's content and fetch it all again (e.g. from the
> remote server)?
> 

No.

> This would be useful for the SugarCRM resource I'm working on: I realized
> that the resource didn't save all of the attributes, so now users have
> incomplete objects. The only way to fix that is to force a redownload.
> 

Yes, that's why the imap resource in some cases ends up re-retrieving
all data from a folder,
if it detects such a case. Detecting them can be difficult though.

> akonadiconsole has a "Clear Akonadi Cache" (in the browser tab, RMB on
> collection), but it's not properly implemented:
> 
> void BrowserWidget::clearCache()
> {
>   const Collection coll = currentCollection();
>   if ( !coll.isValid() )
>     return;
>   QString str = QString("DELETE FROM PimItemTable WHERE
>   collectionId=%1").arg(coll.id());
>   qDebug() << str;
>   QSqlQuery query( str, DbAccess::database() );
>   if (query.exec() ) {
>     if (query.lastError().isValid()) {
>        qDebug() << query.lastError();
>        KMessageBox::error( this, query.lastError().text() );
>      }
>   }
> }
> 
> Surely this is incomplete, it leaves the additional files lying around,
> right?
> (So this is why I had a huge amount of cruft in file_db_data....)
> 

I recently stubled over a similar problem, for all I know file_db_data
is in the regular case at least not cleaned up at all.
Every time a revision is written (e.g. because some email flags
changed),
the old part simply remains on disk.

So the missing part you're seeing above is a general problem I think (at
least I coulnd't
find the codepath that does the cleanup, and I had many revisions for
the same item on my system).

The cleanup codepath is easy enough to add on the server, but that will
result in missing
parts in case of a transaction being rolled back (because we can't
roll-back the removal
of the part files).

As a workaround you can do "akonadictl fsck" to cleanup orphaned parts
after using
the method from akonadiconsole.

> Or maybe I'm looking at this the wrong way, and simply doing a full
> listing in retrieveItems()
> (instead of just listing the modified stuff since last sync) and then
> doing
> itemsRetrievedIncremental(full_list_of_new_items, Item::List());
> should be enough?
> This replaces items with the same ID, and doesn't accumulate files in
> file_db_data, right?

Yes, doing a full listing will replace your items, and is therefore
likely what
you want to do.

Cheers,
Christian
_______________________________________________
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/


More information about the kde-pim mailing list