[Nepomuk] KMail/Akonadi searching

[Sebastian Trüg]

On 01/19/2012 03:34 PM, Ignacio Serantes wrote:
> On Thu, Jan 19, 2012 at 3:07 PM, Sebastian Trüg <trueg at kde.org> wrote:
>> Hi Christian,
>>
>> as most of the code is rather akonadi-specific I can only comment on
>> small parts. Please tell me if I can help with any additional
>> information or questions.
>>
>> In NepomukSearch::hitsAdded you do this query:
>>
>> select distinct ?r ?reqProp1 where {
>>   { ?r a ?v2 . FILTER(?r=<%1>) .
>>     { ?r aneo:akonadiItemId ?reqProp1 . }
>>   } .
>>   ?r nao:userVisible ?v1 . FILTER(?v1>0) .
>> } LIMIT 1"
>>
>> why not write it as:
>> select distinct ?r ?reqProp1 where {
>>   %1 a ?v2 .
>>   %1 aneo:akonadiItemId ?reqProp1 .
>> } LIMIT 1
>>
> 
> I think you forgot the AS clause if the ?r column with a value is required.
> 
> SELECT DISTINCT %1 AS ?r ?reqProp1
> WHERE {
>   %1 a ?v2 .
>   %1 aneo:akonadiItemId ?reqProp1 .
> } LIMIT 1
> 
> My apologies if I'm wrong :).

Oh, yeah, right. But since they already have the resource I doubt they
rely on it being in the query result. Still it is a good hint. :)

Cheers,
Sebastian

>> after all you already know the resource. Thus there is no need to check
>> the visibility or use a filter which might slow down the query (not sure
>> how good the query optimizer handles this case).
>>
>> Cheers,
>> Sebastian
>>
>>
>> On 01/19/2012 01:43 AM, Christian Mollekopf wrote:
>>> Hey,
>>>
>>> I spent today to improve the searching situation a bit, but couldn't fix all
>>> problems yet. It's a more of a workaround than a real fix as you can see but at
>>> least basic searching works this way. A better solution will need changes in
>>> some more places and probably nepomuk-core available (As I don't really feel
>>> like copying more stuff from the nepomuk repository).
>>>
>>> Additionally to nepomuksearchengine I also fixed nepomuksearch, although I
>>> don't know if it is used at all (I also haven't tested this part).
>>>
>>> I also added on commit to kdepim (cbd7a8777a4bfd89125be4cf58e276b51388adc5)
>>> which quotes the search string, because otherwise a searchpattern consisting
>>> of several words is not interpreted as one pattern but rather the AND-
>>> conjunction of each individual word.
>>>
>>> Apart from the current solution being a rather ugly hack, there also exist two
>>> other problems:
>>>
>>> - The search collection is indexed and then searched which is probably not
>>> what we want. If somebody can tell me how to determine the search collection
>>> (by some attribute or so) I could exclude it from the feeder. Another option
>>> would be to exclude it by adding a IndexPolicyAttribute to the search
>>> collection.
>>>
>>> - Each query gets somehow executed twice. I can't see the call twice on the
>>> kmail side, but on the akonadi-server there are always two queries, no idea
>>> why.
>>>
>>> Apart from those issues and the feeder not having indexed all emails here it
>>> works pretty well. The search itself seems pretty fast: ~1-3 seconds for a
>>> query resulting in a small result set, which searches through fulltext/and
>>> headers in ~80000 indexed emails. If the result set is large filling the table
>>> seems to be much more of a bottleneck than the actual query.
>>>
>>> If the attached fixes are applied to akonadi and we manage to exclude the
>>> search collection, we'll have at least half-way decent searching in 4.8.
>>>
>>> Cheers,
>>> Christian
>>>
>>>
>>>
>>> _______________________________________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org
>>> https://mail.kde.org/mailman/listinfo/nepomuk
>> _______________________________________________
>> Nepomuk mailing list
>> Nepomuk at kde.org
>> https://mail.kde.org/mailman/listinfo/nepomuk
> 
> 
>