Summary: | cannot upgrade mysql db from v7 to v9 | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Kusi <kusi> |
Component: | Database-Mysql | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 5.9.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 6.0.0 |
Description
Kusi
2018-05-15 20:02:27 UTC
Your database is probably very old. I can not reproduce at what time the "name" column in the "Images" table was a BLOB/TEXT field. Log into the database with mysql and do this: UPDATE Settings SET value=9 WHERE keyword='DBVersion'; Create a new digiKam database. Then start digiKam and use the migration tool to export the old current database to the new. Maik my db is over 12 years old I guess. Looking at the mysql dump, there's indeed alot of garbage (many unneeded constraints and indexes) compared to how a new db looks like. Digikam with db v9 is now running, but I'll probably do the migration to a new db anyways. Just one question: do the ids for the images change during migration? I've added another table (for another project) whos foreign key is images.id. Therefore I currently rely on Images.id not being changed No, the image ids do not change. Presumably, many orphaned will no longer exist after the migration. The database will certainly be smaller, but nothing should be lost. Maik Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle available here : https://files.kde.org/digikam/ I solved the issue by export/import of the database. That is probably good enough also for other users with this issue. I'm closing this bugreport workaround in comment #1 is good enough |