[Kde-pim] [Nepomuk] KMail/Akonadi searching

[Christian Mollekopf]

On Friday 20 January 2012 01.21:35 Christian Mollekopf wrote:
> I commited/backported the changes for basic working search.
> 
> This means we need a new akonadi release for this to be working in 4.8.
> 
> There are still plenty of problems to solve though:
> - The Search/Last Search folder is mostly shown as parent collection
> - It's not possible to stop queries (which can be annoying when a large
> query was issued)
> - There is no visual feedback that a query is running.
> - The model which displays the results seems very slow
> - When searching for sender/recipient only the email address matches and not
> the name (which is a little unexpected from a user pov).
> - I still have duplicates in the shown result set (although not in the query
> result set)

Nevermind the duplicates. I actually have multiple akonadi items containing 
exactly the same message from back in the days when akonadi used to go 
berserk.

> 
> Most of these issues are in the kmail code as far as I can see, so that
> might need a brush over. Maybe something for the upcoming pim sprint.
> 
> Cheers,
> Christian
> 
> On Thursday 19 January 2012 01.43:12 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
> 
> _______________________________________________
> 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/
_______________________________________________
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/