about akonadi

[Kevin Krammer]

On Thursday, 2010-03-25, Duncan wrote:

> Next question, then. =:^)
> 
> Gentoo recently updated from mysql-5.0 to 5.1.  Apparently, mysql doesn't
> always maintain database compatibility on minor upgrades, so the upgrade
> might have screwed up... at least the cache for... just the address book
> this time, if appropriate database upgrade measures weren't undertaken
> with the upgrade.  Now for folks running mysql as a database that they
> know of and intend to have, fine, they know to be cautious about such
> things.  But now we're talking ordinary desktop users just pulling in
> mysql as a kde dependency.  All they care about is that their kde just
> works.

That is a good question.
I think none of the Akonadi developers were aware that MySQL was so 
unreliable. especially given it is  quite often being used in "enterprise" 
setups.
MySQL seems to have a very different definition of minor releases, even 
configuration options stop working (or worse start generating errors).

If I remember correctly some of the distributors (probably all by now) have 
found some kind of solution to this, but since I haven't run into this myself 
yet I am not sure how it works (just remember reading something related once 
or twice on distributor lists).

Fortunately Akonadi is designed such that it does not strictly depend on a 
single database so we might see a switch in default some time in the future 
(current codebase sees a lot of improvements for Postgres, improvements on the 
Qt driver for Virtuoso could make that a compelling alternative especially for 
KDE users).

> Now, what happens with kde 4.5, when kmail is dependent on mysql, at least
> for caching as we've seen, and these desktop users with little clue
> they're even running mysql as it's simply a kde dependency, pull in the
> next mysql upgrade?

I am not sure this is actually pulled in automatically. I am on Debian 
unstable and MySQL 5.1.x has been available for quite some time now, but my 
installation still says 5.0.y so my guess is that unless something explicitly 
requests the new version the old one is being used and satisfies the 
dependency tree just fine.

> Is that going to break kmail until they run some sort of akonadi/kde
> utility to fix it?  Is there even such a utility, or will users be
> expected to groke the mysql documentation to fix things?  Or will akonadi
> detect the problem and automatically rebuild its cache/indexes/whatever,
> in non-zero but "reasonable" time (possibly with a nice slider widget like
> the one that pops up now when kde starts... maybe that's doing a startup
> check to see if a rebuild is necessary?), where "reasonable" might be
> defined as a few minutes while the user can do other stuff, before their
> mail is again available?

Rebuilding the cache can basically be done on-demand, i.e. as mail parts (e.g. 
headers, body) get requested they will be cached.
Big problem of course for mail not stored locally, e.g. on an IMAP server, so 
my guess would be that this would be a last resort.

Another problem with the rebuild approach is the reverse caching, i.e. 
modifications to data not yet written to the backends (e.g. mails originating 
from an IMAP server being marked as important while the system is offline, 
thus changes being only present in the Akonadi cache).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20100325/54da8546/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.