Bug 393925 - UpdateSchemaFromV7ToV9 fails due to duplicate key in album_2
Summary: UpdateSchemaFromV7ToV9 fails due to duplicate key in album_2
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Migration (show other bugs)
Version: 5.9.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-06 19:54 UTC by Theo van Rijn
Modified: 2018-05-10 23:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 6.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Theo van Rijn 2018-05-06 19:54:21 UTC
After upgrading to Digikam 5.9.0, the database upgrade failed with this error:

digikam.dbengine: Loading SQL code from config file "/usr/share/digikam/database/dbconfig.xml"
digikam.dbengine: Checking XML version ID => expected:  3  found:  3
digikam.coredb: Core database: running schema update
digikam.coredb: Core database: have a structure version  8
digikam.coredb: Core database: makeUpdates  8  to  9
digikam.dbengine: Failure executing query:
 "" 
Error messages: "QMYSQL: Unable to execute query" "Duplicate entry '111-dsc00025.jpg' for key 'album_2'" 1062 2 
Bound values:  ()
digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV9" ] Statement [ "ALTER TABLE Images MODIFY COLUMN name LONGTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;" ]
digikam.coredb: Core database: schema update to V 9 failed!
digikam.coredb: Core database: cannot process schema initialization

A query on the Images table showed there was one row with album = '111' and name = 'dsc00025.jpg'. I found 2 indexes on the table Images ('album_2' and 'album_3') that are not defined in dbconfig.xml. After dropping both indexes the migration was smooth & Digikam started normal.

My Digikam database is ancient and must have been updated numerous times. I expect these superfluous indexes were created by earlier updates. I found more  duplicate indexes on tables like AlbumRoots, Album & Tags. A function to drop such superfluous indexes on migration might help to prevent data migration issues.

I raised this bug to make you aware. For me the issue is solved already.
Comment 1 Maik Qualmann 2018-05-07 05:55:25 UTC
I think this has really been a very individual problem. Also, in the history of dbconfig.xml I can not see that digiKam has ever created this indexes. I would also recommend you to export your old DB with the migration tool to a new one, in order to clean it up as well.

Maik
Comment 2 Maik Qualmann 2018-05-10 06:13:06 UTC
Git commit 8f957ac0e192de2f1c35d76b1ad7d13b1abd8325 by Maik Qualmann.
Committed on 10/05/2018 at 06:11.
Pushed by mqualmann into branch 'master'.

there are no problems if we delete these extra indexes as well
FIXED-IN: 6.0.0

M  +2    -1    NEWS
M  +2    -0    core/data/database/dbconfig.xml.cmake.in

https://commits.kde.org/digikam/8f957ac0e192de2f1c35d76b1ad7d13b1abd8325
Comment 3 Theo van Rijn 2018-05-10 23:25:20 UTC
The migration tool worked like a charm, the new schema does not have any of the superfluous indexes any more. The DB size shrank from almost 2GB to just over 200MB. Thanks Maik! For both solutions.