Error migrating database to MySQL, due to DownloadHistory key length
jsbain at yahoo.com
jsbain at yahoo.com
Sun Feb 26 05:06:59 GMT 2017
I am setting up digikam, and was attempting to use it with an external MySQL database running on my Nas (MyCloud EX2 Ultra). MyCloud comes with an older version of MySQL, without InnoDB compiled in.
When attempting to migrate my database to the external MySQL, I was getting errors creating the schema. Running the queries by hand, I found that when creating the DownloadHistory table, I was getting “Specified key was too long; max key is 1000 bytes” errors.
The issue seems to be that the creation looks like:
```
CREATE TABLE IF NOT EXISTS DownloadHistory (id INTEGER PRIMARY KEY NOT NULL AUTO_INCREMENT, identifier LONGTEXT CHARACTER SET utf8 COLLATE utf8_bin, filename LONGTEXT CHARACTER SET utf8 COLLATE utf8_bin, filesize BIGINT, filedate DATETIME, UNIQUE(identifier(164), filename(165), filesize, filedate)) ENGINE InnoDB
```
Since this uses utf8, which uses 3 bytes per character, the size is 3bytes * (164+165) + 8 + 8 = 1003 bytes.
The Identifier field seems to only actually consume 32 (latin, not utf8) characters currently, so 164 seems like overkill.
I was able to edit my dbconfig.xml to simply change the 164 to a 163, thus saving 3 bytes and getting below the 1000 byte limit. Should I submit a bug report? From what I’ve read, this would impact InnoDB tables as well (max length 767 bytes?), in which case the 164 should be changed to 85, or else utf8 should be changed to latin1. I will say it was nice that all the setup logic was in the xml file, making it easy to change without recompiling!
-jb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170226/f7c67be1/attachment.html>
More information about the Digikam-users
mailing list