Akonadi: Lookup Contact by UID Help please
Klaas Freitag
kraft at freisturz.de
Thu Aug 17 14:18:45 BST 2017
Am 18.04.2017 um 22:52 schrieb Daniel Vrátil:
Hi,
some other findings on this issue, which was fixed a while ago.
>> 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 realized that with Akonadi 17.04.3, the search again was not working.
I found that akonadi-search, which is a separate package on my distro,
was not installed, and installed it.
After that, the search still was not working. Also not after restarting
Akonadi. I had to remove the addressbook agent in akonadiconsole and add
a new one. After that it works again.
Is there a possibility to find a more user friendly solution for this case?
Thanks,
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
More information about the kde-pim
mailing list