[Kde-pim] nepomukfeederagent optimization

[David Faure]

As the TODO said (see patch below), there's really no reason to re-index an email
when doing "marking email as read/unread", or when it gets a new REMOTEID due to that (on local maildir).

Any other case we could skip?
ATR:MDNStateAttribute ?

Maybe we can also do this the other way round, and trigger on PLD:HEAD and PLD:RFC822 only?

I have no idea what else exists.

diff --git a/agents/nepomukfeeder/nepomukfeederagent.cpp b/agents/nepomukfeeder/nepomukfeederagent.cpp
index 5cd5efb..f6ebffb 100644
--- a/agents/nepomukfeeder/nepomukfeederagent.cpp
+++ b/agents/nepomukfeeder/nepomukfeederagent.cpp
@@ -144,11 +144,15 @@ void NepomukFeederAgent::itemAdded(const Akonadi::Item& item, const Akonadi::Col
 
 void NepomukFeederAgent::itemChanged(const Akonadi::Item& item, const QSet< QByteArray >& partIdentifiers)
 {
-  kDebug() << item.id();
-  Q_UNUSED( partIdentifiers );
+  QSet<QByteArray> parts = partIdentifiers;
+  parts.remove( "FLAGS" );
+  parts.remove( "REMOTEID" );
+  // Nothing to re-index if only the flags have changed, or only the remote ID
+  if ( parts.isEmpty() )
+    return;
   if ( indexingDisabled( item.parentCollection() ) )
     return;
-  // TODO: check part identfiers if anything interesting changed at all
+  kDebug() << item.id() << partIdentifiers;
   mQueue.addItem( item );
 }
 
Context: I saw lots of output from this method when "marking all emails as read" in a local folder
(which is already pretty slow due to the change recorder saving all the time, let's not in addition
trigger lots of nepomuk activity for nothing).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

_______________________________________________
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/