Bug 409753 - Duplicate column name 'version' QMYSQL
Summary: Duplicate column name 'version' QMYSQL
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 5.11.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 409853 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-12 19:01 UTC by Matthijs Tijink
Modified: 2019-07-26 12:54 UTC (History)
7 users (show)

See Also:
Latest Commit: https://cgit.kde.org/akonadi.git/commit/?id=8b8db29d10b2ef92deb2d87ff613f3d7f39af34e
Version Fixed In: 5.12.0

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
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.