Akonadi: Lookup Contact by UID Help please

[Klaas Freitag]

Am 18.04.2017 um 22:52 schrieb Daniel Vrátil:
> On Tuesday, April 18, 2017 9:44:39 PM CEST Daniel Vrátil wrote:

Hi Dan,

>> I reproduced the issue on a simple test case. the problem seems to be a
>> combination of how we index the UID and your specific UID format - the dash-
>> separated strings. All our unit tests only used simple UID strings (like
>> "uid1"), which worked. Just changing the testcase UID to
>> "abcd-efgh-1234-5678" broke the test. I'm looking into it now.
> 
> I pushed a fix to akonadi-search that should make searching by UID work. If you 
> want to have it locally, you can build akonadi-search from Applications/17.04 
> branch locally for now, the patch will be present in next bugfix release on May 
> 11.

I pulled the patch into my akonadi-search package (version 16.12.3)
using open Buildservice and can confirm that looking up via UID now works!

Thanks so much for your help, I am really happy that you were finally
able to nail that down.

Akonadis contact handling has given me (and users) a lot of headache in
Kraft so far, also in KDE4. But I think Akonadi is a cool concept and
I'd like to keep on with it, so great that we took this hurdle.

Although there is not a lot noise around Kraft it is used "in
production" out there by some people and I am maintaining it. Thanks for
considering that :-)

regards,
Klaas

> 
>>
>> On Tuesday, April 18, 2017 9:07:20 PM CEST Klaas Freitag wrote:
>>> Am 18.04.2017 um 12:01 schrieb Daniel Vrátil:
>>> Hi Dan,
>>>
>>> thanks for your help. We make progress ;-)
>>>
>>>>> 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.
>>>
>>> That seems to be the case. The ID _is_ 3.
>>>
>>> I tested something different and searched for the email rather than the
>>> the UID, otherwise no change. That worked perfectly fine, the Contact
>>> was returned.
>>>
>>> So the problem seems to only exist when searching for UID.
>>>
>>> Just a wild guess: Maybe there is a number versus string problem
>>> somewhere in the underlying code? Maybe the UID is expected as numerical
>>> type somewhere?
>>>
>>> thanks,
>>>
>>> Klaas
> 
> 


-- 
Kraft - KDE Software zur Rechnungslegung für Kleinunternehmen