[Kde-pim] Address Query with ContactSearchJob in KDE 4.13.0

[Daniel Vrátil]

On Monday 28 of April 2014 12:03:57 Klaas Freitag wrote:
> On 28.04.2014 09:17, Daniel Vrátil wrote:
> 
> Hi,
> 
> thanks Dan for your reply. I'll try that.
> 
> > If you only want to search by UID, you can use GID fetch. GID is
> > identifier of content of the item (UID for vCards, UID for iCals,
> > Message-Id for emails, etc), which is stored directly in Akonadi.
> > 
> > You can use regular ItemFetchJob to fetch items by GID:
> > 
> > Item item;
> > item.setGid("Kp9LZPRW8P");
> > ItemFetchJob *fetch = new ItemFetchJob(item, this);
> > ...
> > ...
> > 
> > Since GID is not guaranteed to be unique, you might want to use
> > fetch->setCollection() to specify from which collection to fetch (it also
> > speeds up the lookup a lot) if you work only with one collection.
> 
> Hmm, I'd like to search through all address books. Is there a way to
> express that as Collection?

No, but see below.

> You said that the is not guaranteed to be unique. Does that mean that
> there could be two contacts with the same GID, or that there could be an
> email and a contact with the same GID?

There could be more contacts (more Akonadi Items) with the same GID but with 
completely different content. This should not happen within a single resource, 
but could theoretically happen if you are working with multiple Akonadi 
resources. For instance: you have to vCard resources and you import the same 
contact to both.

In theory, the results can even include items other than contacts, so you 
should always iterate over all items returned by the fetchJob and check, 
whether item.hasPayload<KABC::Addressee>() and discard the others.

> 
> And, this solution is backward compatible, ie. works with previous KDE
> versions as well, right?

GID was introduced in 4.12 and Akonadi 1.11.0. If you want to support older 
versions, you have to use Nepomuk.

Dan

> 
> Thanks,
> 
> Klaas
> 
> > Dan
> > 
> >> I'd appreciate any hints on how this problem could be solved, for me to
> >> improve Kraft and for Kraft's users who are often non tech people who
> >> get into trouble if they update to a more recent KDE version and see
> >> this breaking, as they fear to be not longer able to send out invoices.
> >> That is a uncomfortable situation for them which makes them quickly
> >> running away ;-)
> >> 
> >> If that is a problem like "baloo does not have this functionality yet"
> >> its fine but than I would like to inform Krafts user to _not_ update yet.
> >> 
> >> Thanks for your help & and the great improvements recently,
> 
> _______________________________________________
> 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/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140428/9c05674e/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/