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
Attachment:
signature.asc
Description: This is a digitally signed message 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.
