Bug 262231 - Missing records after migration from SQLite to Digikam
Summary: Missing records after migration from SQLite to Digikam
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Database-Migration (show other bugs)
Version: 1.6.0
Platform: Fedora RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-05 20:42 UTC by Vincent Tassy
Modified: 2017-07-25 10:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Tassy 2011-01-05 20:42:02 UTC
Version:           1.6.0 (using KDE 4.5.4) 
OS:                Linux

I've run the migration tool and then looked at the content of the
supposedly synced SQLite and MySQL databases ...

                          Records
Table               SQLite      MySQL
-------------------------------------
AlbumRoots               2          2
Albums                 808        808
DownloadHistory     13,403     13,403
ImageComments        5,969      5,969
ImageCopyright      50,303     50,303
ImageHaarMatrix     27,756     27,756
ImageInformation    81,216     81,216
ImageMetadata       72,383          0
ImagePositions       6,481      6,481
ImageProperties         50         50
Images              81,216     81,210
ImageTags           52,463     52,463
Searches                15         15
Settings                20         11
Tags                   461        461
TagsTree             1,886      2,240

As you can see, most tables seem to have been migrated correctly but
ImageMetadata is empty, Images is missing 6 records, Settings is missing
9 and TagsTree is abnormally bigger !


Reproducible: Always

Steps to Reproduce:
Perform Database migration

Actual Results:  
ImageMetadata table is empty
Images table is missing 6 records
Settings table is missing 9 records
TagsTree Table has more records than source table !!

Expected Results:  
Source and Destination Database should be perfectly in sync

I found that while the migration was going, the more it advanced, the slower it was ...
When the progressbar indicated the migration of the TagsTree table it took more than 10 minutes ! while the migration of the Images table took a few seconds ...
Comment 1 caulier.gilles 2011-01-05 22:08:44 UTC
There is 2 investigations to do there :

1/ Check with 1.7.0 release. I remember that some fix have be done about mysql schema rules. Perhaps it's fix this problem with production series.

2/ digiKam 2.0.0 beta1 is out with a lots of improvements and new features. DB schema have been changed in-deep and a similar check must be done with it. take a care, it's not yet stable. Do not use it in production.

Gilles Caulier
Comment 2 Vincent Tassy 2011-01-06 14:17:37 UTC
Just tested with 1.7.0

I got the exact same numbers after the migration

Am going to test 2.0.0b1 now ...
Comment 3 Francesco Riosa 2011-05-09 17:02:30 UTC
@bug_id = 262231
@bug_status = RESOLVED
@resolution = FIXED

Git commit ec7ceeea0d2587abb9f1bdd17109d4903998e943 by Francesco Riosa.
Committed on 09/05/2011 at 14:20.
Pushed by riosa into branch 'master'.

more resilient database upgrade and startup

All statements are made resilient to a partially upgraded database.
- CREATE TABLE are done with IF NOT EXISTS
- TRIGGERs are dropped and re-created
- a new stored procedure is added "create_index_if_not_exists"
  the procedure check in information_schema if the index exists,
  if not does create it
- all INDEXes are created using "create_index_if_not_exists"

BUG: 271924
BUG: 258409
BUG: 257183
BUG: 267733
BUG: 262231
BUG: 233770

M  +90   -56   data/database/dbconfig.xml.cmake     

http://commits.kde.org/digikam/ec7ceeea0d2587abb9f1bdd17109d4903998e943