[Kde-pim] Porting StdAddressBook to Akonadi does not work as Akonadi::ContactSearchJob returns no results

[Kevin Krammer]

Hi,

On Wednesday, 2013-02-06, Cristian Oneț wrote:
> Hi,
> 
> I'm having problems replacing the deprecated StdAddressBook API with
> the new Akonadi::ContactSearchJob API (in KMyMoney) as it's
> recommended here [1]. The problem is that it does not work as expected
> since the ContactSearchJob returns no results with Nepomuk disabled.
> This dependency is not mentioned in the porting guides that I've read
> so it's a bit frustrating since I had Nepomuk turned off due to the
> often recurring 100% CPU usage issues.

At the time of writing I assumed that Nepomuk would always be running in a PIM 
setup due to many things depending on effective search.
Since it is a living document you can of course update it when you've found an 
alternative solution that is accetable for your use case and document its 
assumptions as well.

> At this point I went on and enabled Nepomuk together with the email
> indexer. I waited for the indexer to finish it's initial indexing.
> Then ran the ContactSearchJob again. This time the search by email
> query took about 1 minute of 100% CPU usage from Nepomuk (I have 45
> contacts in my address book) but again without any results. Even tried
> to run the 'Search contact by email' query from the Akonadi console
> but all I've got on Akonadi's output was 'QStringList
> Akonadi::NepomukSearch::search(const QString&) Calling blockingQuery()
> failed! '.

No idea there.

> From there I've found out that in 4.10 KMail will be able to perform
> the auto completion without Nepomuk [3]. I've tried a similar approach
> which works as expected without any issues. The only thing that
> bothers me is that you need to iterate over all contacts to find the
> one that you are looking for (having the email of the KDE user
> obtained with IdentityManager).

This is the runtime equivalent of what StdAddressBook did. You can potentially 
improve on that by only loading minimal contact payloads (ContactPart::Lookup, 
see akonadi/kabc/contactparts.h) while searching.

> Anyway for my 45 contacts this works as expected and a lot faster then the
> whole Nepomuk indexing engine.

This is definitely strange. The whole point of using an index for search is to 
make it faster than simple linear search.
Do you also get this speed difference when both approaches use the same data 
set? I.e. when you do not use mail indexing (and thus adding all address 
contained in emails).

> I'm writing this mail because I've tried yesterday (without success)
> on #akonadi to get some hints about what could be wrong with Nepomuk
> on my setup. Maybe I could provide valuable information to fixing [2]
> I just need to know where to look.

Maybe the wrong channel. I think Nepomuk people mostly hang out in #nepomuk-
kde

> About searching trough the contacts in Akonadi without Nepomuk [3]. Is
> it OK to use it in non-KDEPIM applications?

From the point of view of the Akonadi setup there is no difference between 
applications. It offers functionality and you use that in any way you see fit.

KDEPIM applications could be seen as a starting point for looking for usage 
patterns, however due to their age and complexity they are often not yet using 
Akonadi in the best possible way.

> Isn't there an easier way
> to obtain the Akonadi:Item using the email address?

There are three options:
- linear search: walking through all contacts, compare addresses (potentially 
only loading partial contacts, see above)

- loading all contacts and sorting by email, then doing local lookup

- using the search facility. naturally this one is expected to be the most 
efficient (delegating the lookup to a component specialized in search). No 
idea why that is not the case for your setup.

> Do you see some
> performance issues in this approach?

Probably taking a bit more time than the StdAddressBook approach due to more 
round-trips, but on the other hand potentially needing less memory (not having 
to load all contacts in full) and being fully asynchronous.

> I would prefer this approach
> since it works with Nepomuk disabled which is a possible scenario (the
> user can do it from SystemSettings).

Detecting that is something we might need to have a common solution for.
E.g. an application requiring lookup would just instanciate a checker and that 
checker would probe the system and display an application specific hint if 
some functionality is temporary unavailable until Nepomuk is enabled.

On the exmaple of KMail something like "KMail has detected that you have 
disabled contact search. Please enable if you want to use address completion 
or contact groups."

Of course assuming that whatever makes contact search so slow in your case can 
be fixed.

If not we might consider a customs search service for most common PIM queries 
and have e.g. ContactSearchJob use that (or use it as a fallback). I.e. allow 
applications to always use the search job.

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/20130208/dd78446d/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/