Re: Akonadi dsaster

Daniel Vrátil <[email protected]> Fri, 14 Oct 2016 10:54:31 +0200
Newsgroups	gmane.comp.kde.users.pim
Organization	KDE
Message-ID	<1657859.c39AfZshez@mjollnir>
On Friday, October 14, 2016 10:38:09 AM CEST René J.V. Bertin wrote:
> On Friday October 14 2016 09:03:29 Daniel Vrátil wrote:
> >This comes from the "Baloo file extractor" AFAIK, which now uses
> >LMDB/SQLite. Historically Akonadi Search uses ~/.local/share/baloo, and so
> >it's likely that some generic Xapian DB lookup code in our Search code
> >finds it and complains that it's not a Xapian DB.
> >
> >If you use the Baloo file extractor the I think you should not remove that,
> >otherise you can remove it.
> 
> It being the .local/share/baloo directory?

.local/share/baloo/file

.local/share/baloo/anything-else-but-file still contains your indexed emails 
etc. (unless you have already migrated to .local/share/akonadi/search_db, in 
which case you can kill the entire ~/.local/share/baloo)

> 
> >I would like to see some sort of a self-balancing configuration, where the
> >database could "suggest" optimal settings based on long-time load and
> >available hardware resources. That would magically solve the issue
> >described above, but that's more of a day-dreaming :-)
> 
> Not necessarily. As you say, there are 2 population groups who could
> complain about the default settings, and one of those is likely to be
> perfectly capable of following tuning instructions. So, if you can write an
> algorithm that keeps track of actual usage and then provide sensible
> settings from that, those power users can edit their .cnf file to copy the
> tuned values.
> 
> It would be just as possible to do this through the akonadi bootstrap
> routine; you probably already have a .cnf template somewhere, in which you
> could easily replace certain hardcoded default values with a token that
> gets replaced by a tuned value. Personally I'd want to be really sure that
> those tuned values are sensible though, before allowing automatic hacking
> of my configuration file (which might contain other tweaks of my own).

Yeah, obviouisly some "don't autotune my fine-tuned configuration" option 
would be needed. The hardest part is to come up with an algorithm that can 
autotune the values correctly.

Might be something for the DB guys here to try figure out ;-)


> > It's true that the indexer currently ignores the NoIndexing attribute.
> > That's bug and should be fixed.
> 
> Recent regression or long-standing bug (since 4.1x)?

I could swear that there was at least partial support in 4.1x, but grepping 
current codebase I don't see any handling of the IndexPolicyAttribute at all, 
so probably a regression :(

> 
> > Akonadi Search is based on the old Xapian-based Baloo, which had a good
> > error handling.
> 
> Side-ways related: does email search/indexing still work on platforms where
> Baloo itself no longer works (AFAIK anything other than Linux)? I already
> see a reduced functionality in email search (presumably rather in the
> indexing) in KDE PIM 4.13 and 4.14 on OS X w.r.t. Linux, and 4.1x Baloo
> still works as intended otherwise on OS X. It'd be a pity not to have any
> search functionality - if KDE PIM 5 has the objective of being
> cross-platform of course.

Akonadi Search works on all platforms where Xapian is available. There are no 
other requirements.

Note that there is absolutely no relation between KF5 Akonadi Search and KF5 
Baloo (which is using LMDB and xattr). Akonadi Search is built on "fork" of 
some KDE4 Baloo code, but we don't really speak of Baloo anymore anywhere to 
avoid the confusion. I think I finally managed to remove all references to 
Baloo from code and UI everywhere now :)


Dan

> 
> 
> R.


-- 
Daniel Vrátil
www.dvratil.cz | [email protected]
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc (application/pgp-signature, 819 B)