Version: 1.6.0 (using KDE 4.5.4)
I've run the migration tool and then looked at the content of the
supposedly synced SQLite and MySQL databases ...
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 !
Steps to Reproduce:
Perform Database migration
ImageMetadata table is empty
Images table is missing 6 records
Settings table is missing 9 records
TagsTree Table has more records than source table !!
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 ...
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.
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"
M +90 -56 data/database/dbconfig.xml.cmake