| Summary: | Missing records after migration from SQLite to Digikam | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Vincent Tassy <timetre> |
| Component: | Database-Migration | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, vivo75+kde |
| Priority: | NOR | ||
| Version: | 1.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.0.0 | |
| Sentry Crash Report: | |||
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 Just tested with 1.7.0 I got the exact same numbers after the migration Am going to test 2.0.0b1 now ... @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 |
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 ...