Akonadi: Lookup Contact by UID Help please

[Klaas Freitag]

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?
>
> 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?

Also I can not find the example file you mentioned above unfortunately. 
Is it in some secret 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?

>
> 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?

Thx,

Klaas
>