Akonadi: Lookup Contact by UID Help please

Tue Apr 18 11:01:00 BST 2017

Hi Klaas,

On Tuesday, April 11, 2017 12:57:06 PM CEST Klaas Freitag wrote:
> Hi Sandro,
> 
> thanks for your answer!
> 
> On 08.04.2017 15:48, Sandro Knauß wrote:
> > Hi Klaas,
> > 
> >> in my application Kraft [ http://volle-kraft-voraus.de/ ] which I just
> >> ported to KF5 I have a problem fetching contacts from Akonadi. Kraft
> >> stores UIDs as reference to the contacts in Akonadi and I need code that
> >> gets the contact out of Akonadi for a given UID.
> > 
> > Whoo great!
> :
> :-)
> :
> >> In KDE4 times there was a class ContactSearchJob, but it seems that this
> >> is not working any more with UIDs because Baloo does not index the UIDs,
> >> at least that was mentioned somewhen on this list.
> > 
> > well this is not true anymore. You can search again for the UID with the
> > ContactSearchJob. The UID itsself is indexed.
> 
> Do I have to enable that somehow? Can I check with my installation if
> baloo is indexing my contacts?

You did so below, with the quest/delve  commands :)

> 
> > So a normal ContactSearchJob should be fine to fire. There is ConactUid
> > parameter to match. An example how to use ContactSearchJob you'll find in
> > kdepim-addons/plugins/bodypartformatter/vcard/updatecontactjob.cpp
> 
> Since which version? I can not get it to work with this snippet:
> 
> ===>
>      Akonadi::ContactSearchJob *csjob = new Akonadi::ContactSearchJob(
> this );
>      csjob->setLimit( 1 );
>      csjob->setQuery( Akonadi::ContactSearchJob::ContactUid , uid );
>      connect( csjob, SIGNAL( result( KJob* ) ), this, SLOT(
> searchResult( KJob* ) ) );
>      csjob->start();
> <==
> In the respective slot, the search result list has always zero items,
> even though I see the contact with the right UID in akonadi_console.
> Do I have to set a collection or anything before using ContactSearchJob?

Looks correct to me, this should yield the correct result.

> 
> Also I can not find the example file you mentioned above unfortunately.
> Is it in some secret git?

kdepim-addons is in cgit.kde.org/kdepim-addons.git.

> 
> > Keep in mind to set a good FetchScope, to only things you are interesting
> > in, this makes things much faster.
> > To make Kraft future save, I would you to suggest to port away from any
> > use of Akonadi::Item and instead use ContactSearchJob::contacts instead.
> > Also KContacts::Addressee should not leak deep into Kraft, so translate
> > it at one defined place into a  internal representation of a Contact.
> 
> While I understand the Akonadi::Item thing, I am wondering about
> KContacts::Addressee. I wanted to use that actually as internal
> representation in Kraft, because, well, an addressee is an addressee, I
> did not reinvent that in my own class again. What do you think is going
> to happen with it in the longer run?

KContacts is not going away any time soon.

KContacts is closely modelled after VCARD RFC6350 (and friends). Depending on 
how that aligns with your needs how to represents Addressees/contacts/personas 
in Kraft, you *might* want to consider creating a custom domain class and map 
it from KContacts. I don't know Kraft, but if you really only need 
"Addressees" in the sense of actual addressbook-like Addressees, then 
KContacts is the right choice for you IMO.

> 
> > Because it helpes in some cases. here are some commands to perform a
> > search on the akonadi-search database by itself.
> > (UID is a actual UID of a contact):
> > # quest ~/.local/share/akonadi/search_db/contacts '"UID"'
> > Parsed Query: Query(UID at 1)
> > MSet:
> > 899985: [5.80023]
> > 
> > # xapian-delve ~/.local/share/akonadi/search_db/contacts -r 899985
> > Term List for record #899985: C1402 NAknauß NAsandro de i9haczcdcz knauß
> > mail mail at sandroknauss.de sandro sandroknauss
> > 
> > -> as you see "i9haczcdcz" is the UID in my case for the contact
> > -> 899985 is the AkonadiID
> 
> This is actually interesting! See what I get:
> ==>
> [kf:~/pjat/kraft] kf5(+1/-25)+* ± quest -d
> ~/.local/share/akonadi/search_db/contacts
> '"df6748f1-c13d-438c-a4d3-86d395630f92"'
> Parsed Query: Xapian::Query((df6748f1:(pos=1) PHRASE 5 c13d:(pos=2)
> PHRASE 5 438c:(pos=3) PHRASE 5 a4d3:(pos=4) PHRASE 5 86d395630f92:(pos=5)))
> MSet:
> 3 [100%]
> 
> [kf:~/pjat/kraft] kf5(+4/-26)+* ± delve
> ~/.local/share/akonadi/search_db/contacts -r 3
> Term List for record #3: 438c 86d395630f92 C16 NAmarkotiris NArubilos
> a4d3 c13d df6748f1 markotiris rubilos
> <==
> 
> The UID that I have stored in Kraft is
> df6748f1-c13d-438c-a4d3-86d395630f92. But look what delve is retrieving
> as the UID, it is kind of scrambled. The name rubilos markotiris makes
> sense.
> Can you explain that?

The "scrambling" is because for some reason, the UID is indexed as a plain 
text, so Xapian indexes each part of the UID independently (split by the dash-
signs) an in arbitrary order. It means that you should be able to search for 
any contacts with UID that contains "438c", but that does not really make any 
sense and nobody will ever do it. We should fix this and only index UIDs as 
terms.

In Akonadi Console -> Browser open your contacts collection where the contact 
you are trying to search for exists and click the contact. In the lower part 
go to the "Internals" tab and check the "ID". It should say 3. If it does, 
then we have a problem somewhere in Akonadi. If it says a different number, 
then it means that your search index got out-of-sync with Akonadi and returns 
results that refer to Akonadi::Items that no longer exist in Akonadi (and thus 
the search job gives you no results).

Dan

PS: I know the out-of-sync case looks like a bad thing, but it should not 
happen in normal use and soon Akonadi will be able to fix it automatically.

> 
> Thx,
> 
> Klaas

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170418/349896d3/attachment.sig>