From: Adrien <adrien.grellier@laposte.net> To: submit@bugs.debian.org Subject: [digikam] external mysql db empty after database migration Date: Wed, 23 May 2012 19:03:03 +0200 Package: digikam Version: 4:2.6.0~rc-3 Severity: grave Hi, I am using Digikam from testing, with an external MySQL database. The last upgrade has been a total mess : the migration of the database has failed, and my db was totally empty after that. Fortunately I had a backup. I tried to migrate again with the wizard, but it failed the same way. Finally I found a solution : create a second database « digikam2 » (and « digikam_thumb2 » ), and run the wizard to migrate from digikam to digikam2. I recover my pictures, but the tags (stored in nepomuk) disappears… Haven't find any solution to recover them… :(( It seems to have a bug in the db migration, which delete all the data to migrate. Maybe when constructing the new schema ? Anyway, this behaviour should be corrected. Cheers, Adrien --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-2-amd64 Debian Release: wheezy/sid 900 testing security.debian.org 900 testing ftp.fr.debian.org 800 unstable ftp.fr.debian.org 700 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ================================================-+-====================== kde-runtime | 4:4.7.4-2+b1 libc6 (>= 2.4) | 2.13-32 libgcc1 (>= 1:4.1.1) | 1:4.7.0-8 libgomp1 (>= 4.2.1) | 4.7.0-8 libgphoto2-2 (>= 2.4.10.1) | 2.4.14-2 libgphoto2-port0 (>= 2.4.10.1) | 2.4.14-2 libjasper1 | 1.900.1-13 libjpeg8 (>= 8c) | 8d-1 libkdcraw20 (>= 4:4.7.1) | 4:4.7.4-2 libkdecore5 (>= 4:4.7.0) | 4:4.7.4-4 libkdeui5 (>= 4:4.7) | 4:4.7.4-4 libkdewebkit5 (>= 4:4.7) | 4:4.7.4-4 libkexiv2-10 (>= 4:4.7.1) | 4:4.7.4-2+b1 libkfile4 (>= 4:4.7) | 4:4.7.4-4 libkhtml5 (>= 4:4.7) | 4:4.7.4-4 libkio5 (>= 4:4.7.0) | 4:4.7.4-4 libkipi8 (>= 4:4.5.90) | 4:4.7.4-2 libknotifyconfig4 (>= 4:4.7) | 4:4.7.4-4 libkparts4 (>= 4:4.7) | 4:4.7.4-4 liblcms1 (>= 1.15-1) | 1.19.dfsg-1+b2 liblensfun0 | 0.2.5-2 liblqr-1-0 (>= 0.4.0) | 0.4.1-1.1 libmarblewidget12 (>= 4:4.7.1) | 4:4.7.4-2 libnepomuk4 (>= 4:4.7) | 4:4.7.4-4 libopencv-core2.3 | 2.3.1-8 libopencv-highgui2.3 | 2.3.1-8 libopencv-imgproc2.3 | 2.3.1-8 libopencv-legacy2.3 | 2.3.1-8 libopencv-objdetect2.3 | 2.3.1-8 libphonon4 (>= 4:4.2.0) | 4:4.6.0.0-2 libpng12-0 (>= 1.2.13-4) | 1.2.49-1 libqjson0 (>= 0.7.1) | 0.7.1-6 libqt4-dbus (>= 4:4.5.3) | 4:4.8.1-1 libqt4-network (>= 4:4.5.3) | 4:4.8.1-1 libqt4-qt3support (>= 4:4.5.3) | 4:4.8.1-1 libqt4-sql (>= 4:4.5.3) | 4:4.8.1-1 libqt4-xml (>= 4:4.5.3) | 4:4.8.1-1 libqtcore4 (>= 4:4.8.0) | 4:4.8.1-1 libqtgui4 (>= 4:4.8.0) | 4:4.8.1-1 libqtwebkit4 (>= 2.1.0~2011week13) | 2.2.1-4+b1 libsolid4 (>= 4:4.7) | 4:4.7.4-4 libsoprano4 (>= 2.1.67) | 2.7.5+dfsg.1-1 libstdc++6 (>= 4.6) | 4.7.0-8 libtiff4 (>> 3.9.5-3~) | 3.9.6-5 libx11-6 | 2:1.4.99.901-2 phonon | 4:4.6.0.0-2 libqt4-sql-sqlite | 4:4.8.1-1 digikam-data (= 4:2.6.0~rc-3) | 4:2.6.0~rc-3 Recommends (Version) | Installed ============================-+-=========== www-browser | kipi-plugins | 4:2.6.0~rc-3 mplayerthumbs | Suggests (Version) | Installed ==========================-+-=========== digikam-doc | Reproducible: Always
On Thu, 24 May 2012 03:03:03 Adrien wrote: > It seems to have a bug in the db migration, which delete all the data to > migrate. Maybe when constructing the new schema ? Anyway, this behaviour > should be corrected. Adrien, I have forwarded your report upstream: https://bugs.kde.org/show_bug.cgi?id=301075 Could I ask you to provide further details upstream to the KDE bug tracker. Thanks, Mark
Hi, could you please help us providing some more info? To see more debug output launch `kdebugdialog --fullmode` search for 'digikam', activate the debug output, expecially for area 50007 output to information to a file. Launch digikam possibly from a shell, then try to redo the conversion and attach to this bug the result. Also, previous version of digikam?
Created attachment 72034 [details] debug output from digikam
Hi, Sorry for not answering quickly. I tried again the migration, and I got this on the command line : QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-20685328' is still in use, all queries will cease to work. QSqlDatabasePrivate::addDatabase: duplicate connection name 'digikamDatabase-20685328', old connection removed. digikam(25258)/digikam (core): Schema update to V6 failed! I also enable the debug mode, as requested, bhe debug output may not be very useful :-( I also didn't find any solution to recover my tags.
(In reply to comment #4) > I also didn't find any solution to recover my tags. I just notice that the tags are in my new database (I see them with select * from Tags;), but they doesn't appears in digikam. It seems that the db migration has not going well unfortunately.
Official digiKam 2.6.0 release is out since few days now : http://www.digikam.org/drupal/node/656 Please, check if this entry still valid, or update report accordingly. Thanks in advance. Gilles Caulier
(In reply to comment #6) > Official digiKam 2.6.0 release is out since few days now : My problem occurs when passing from 1.9 to 2.6, which is now in Debian testing.
(In reply to comment #7) > (In reply to comment #6) > > Official digiKam 2.6.0 release is out since few days now : > > My problem occurs when passing from 1.9 to 2.6, which is now in Debian > testing. About my problem with tags, it's strange : I can see my tags are imported to my new database « digikam2 », but they doesn't show up in digikam.
(In reply to comment #8) > > About my problem with tags, it's strange : I can see my tags are imported to > my new database « digikam2 », but they doesn't show up in digikam. Hi, I finally retrieve my tags by modifying directly the database. Some of the tags had a missing parents (pid=-1 for instance). After modified the pid to an existing one (pid=0) into the db the tags appears magically into digikam.
The missing pid of tag is a problem already reported to bug #325654 Gilles Caulier *** This bug has been marked as a duplicate of bug 325654 ***
Not reproducible with 7.0.0 beta 1.