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

[Christian Mollekopf]

On Friday 20 January 2012 11.47:39 Stephan Diestelhorst wrote:
> Could it be that these changes destabilized current head? I am seeing
> several search related crashes with today's Project Neon builds.
> Also I have noticed that at some point the search results switch
> between showing what is actually in my IMAP resource and then what is
> in the Last Search folder (containing the same things, becuase I
> repeated the search query) and then dies.

I wouldn't know why. I didn't really change anything in the control flow 
(except for a second blockingQuery in the NepomukSearch class).

The problem with the wrong parent collection lies within the kmail models 
which are probably getting confused because the item is in two collections 
(That's just a wild guess though). That seems more like a task for 4.8.1 
maybe.

Can you provide any backtraces for the search related crashes?
I didn't experience a single crash so far...

Cheers,
Christian

> 
> Stephan
> 
> On 20 January 2012 01:21, Christian Mollekopf <chrigi_1 at fastmail.fm> 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)
> > 
> > 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/
_______________________________________________
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/