Bug 409753

Summary: Duplicate column name 'version' QMYSQL
Product: [Frameworks and Libraries] Akonadi Reporter: Matthijs Tijink <matthijstijink>
Component: serverAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: arojas, asturm, emilianh, faure, Mathias.Homann, wbauer1, wraeth+kdebugs
Priority: NOR    
Version: 5.11.3   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=409234
Latest Commit: https://cgit.kde.org/akonadi.git/commit/?id=8b8db29d10b2ef92deb2d87ff613f3d7f39af34e Version Fixed In: 5.12.0
Sentry Crash Report:

Description Matthijs Tijink 2019-07-12 19:01:41 UTC 
SUMMARY

Akonadi does not start anymore, using either the GUI or "akonadictl start".
It shows the following messages when trying to start with "akonadictl start":

org.kde.pim.akonadiserver: Running DB initializer
org.kde.pim.akonadiserver: "\nSql error: Duplicate column name 'version' QMYSQL: Unable to execute query\nQuery: ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
org.kde.pim.akonadiserver: Unable to initialize database.
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

And then exits immediately (without error code, but I don't know if that's expected or not).

The database (MariaDB) is running, I can connect to it, and indeed the "version" field of "SchemaVersionTable" already exists.


SOFTWARE/OS VERSIONS
Qt Version: 5.13.0
MariaDB version: 10.4.6

ADDITIONAL INFORMATION
I'm not sure when it stopped working, but sometime in the last week. My akonadi updated yesterday (11-07-2019) from version 5.11.2 to 5.11.3, that might be related.
Comment 1 Antonio Rojas 2019-07-16 13:28:55 UTC 
According to downstream reports, this is a regression from 74aed9542ba1ff1e6e93a550c42869647c4eba8e
Comment 2 wraeth 2019-07-17 06:14:40 UTC 
(In reply to Antonio Rojas from comment #1)
> According to downstream reports, this is a regression from
> 74aed9542ba1ff1e6e93a550c42869647c4eba8e

I encountered the same issue with the same version of akonadi on Gentoo, and reverting that specific commit resolved it for me.
Comment 3 Mathias Homann 2019-07-17 07:39:32 UTC 
*** Bug 409853 has been marked as a duplicate of this bug. ***
Comment 4 David Faure 2019-07-21 14:52:59 UTC 
This happens on external MySQL servers, since they don't usually have the option lower_case_table_names=1 enabled, so the (new) toLower() call assumes that option to be present.

So the immediate fix is to lowercase your table names. I'm not sure doing that at the filesystem level is enough, they're probably listed in the global mysql DB too. Instead you can use mysqldump, lowercase the table names, and reimport.

The external MySQL server feature assumes that your MySQL matches the requirements for Akonadi. This includes InnoDB and lowercase table names, at least.
See /etc/xdg/akonadi/mysql-global.conf for the settings used by akonadi.
Comment 5 Matthijs Tijink 2019-07-22 20:29:19 UTC 
Removing the Akonadi database and using the built-in database indeed worked.

Maybe it would be good to document this requirement: I wasn't aware of it (and back when I set it up, this wasn't stated even in the GUI used to configure the external db!), and not entirely expected.

https://techbase.kde.org/KDE_PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F would be a good place.
Comment 6 wraeth 2019-07-24 11:51:30 UTC 
(In reply to David Faure from comment #4)
> So the immediate fix is to lowercase your table names.
To confirm, this has worked for me, though rather than dumping I just ran 'ALTER TABLE Foo RENAME TO foo;' for each of them, then restarted with lower_case_table_names=1 set.