Bug 369083

Summary: database migration sets wrong parent ids for tags
Product: [Applications] digikam Reporter: beaaeecffmiqwryxcmbw2ta2cukc4
Component: Database-MigrationAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: minor CC: caulier.gilles
Priority: NOR    
Version: 5.4.0   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In: 5.8.0
Sentry Crash Report:

Description beaaeecffmiqwryxcmbw2ta2cukc4 2016-09-19 22:07:37 UTC
After a database migration from ... 5? to 8 all tags have vanished.
The migration tools sets the parent ids of those tags to "-1" instead of "0".

Reproducible: Always

Steps to Reproduce:
1. migrate database from old_dbname to new_dbname (mysql external to mysql external)
2. enter configuration
3. set new_dbname as current database

Actual Results:  
tags are neither shown in tag manager nor the images are tagged.

Expected Results:  
tags are available in tag manager and shown on images.

I've been using digikam for ages now without ever upgrading my database. I had to do the following steps to even convert the database successfully:

create table deleteme (id int(11) not null);
insert into deleteme (id) select id from Images where album not in (select id from Albums);
delete from Images where id in (select id from deleteme);
drop table deleteme;
delete from ImageTags where imageid not in (select id from Images);
delete from ImageHaarMatrix where imageid not in (select id from Images);
delete from ImageInformation where imageid not in (select id from Images);
delete from ImageMetadata where imageid not in (select id from Images);
delete from VideoMetadata where imageid not in (select id from Images);
delete from ImagePositions where imageid not in (select id from Images);
delete from ImageComments where imageid not in (select id from Images);
delete from ImageCopyright where imageid not in (select id from Images);
delete from ImageProperties where imageid not in (select id from Images);
delete from ImageHistory where imageid not in (select id from Images);
delete from ImageTagProperties where imageid not in (select id from Images);
delete from ImageRelations where subject not in (select id from Images) or object not in (select id from Images);
delete from ImageTags where tagid not in (select id from Tags);

and after running the migration tool, I got my tags back again using:
update Tags set pid = 0 where pid = -1 and name not like '_Digikam_%';
Comment 1 caulier.gilles 2016-09-20 04:21:00 UTC
Tge migration from 5 to 8 has no chance to be done properly. The Mysql current database Schema has changed to much.

Tips : From old database backup and previous version, store digiKam properties in files metadata and create new database with 5.x from scratch.

Gilles Caulier
Comment 2 caulier.gilles 2016-11-28 11:34:58 UTC
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last
bundle is available at this url:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 3 beaaeecffmiqwryxcmbw2ta2cukc4 2016-12-05 22:17:57 UTC
Yes, it's still broken, all parent ids are set to "-1".
Did a migration from version 8 (digikam-5.3.0-2.fc24.x86_64) to 8 (digikam-5.4.0-01-x86-64.appimage).
Comment 4 Maik Qualmann 2017-11-25 22:04:53 UTC
Git commit 9a17c743ea9a41c1ef050b08517343813ef6a9f4 by Maik Qualmann.
Committed on 25/11/2017 at 22:02.
Pushed by mqualmann into branch 'master'.

update DB to v9 and fix migration from SQLite to MySQL
Related: bug 378838, bug 350574, bug 325654
FIXED-IN: 5.8.0

M  +5    -1    NEWS
M  +129  -97   data/database/dbconfig.xml.cmake.in
M  +1    -1    data/database/mysql-global.conf
M  +1    -20   libs/database/coredb/coredbcopymanager.cpp
M  +5    -2    libs/database/coredb/coredbschemaupdater.cpp

https://commits.kde.org/digikam/9a17c743ea9a41c1ef050b08517343813ef6a9f4