Bug 220903

Summary: Duplicate records in ImageComments table after migration
Product: [Applications] digikam Reporter: cfunghi <cfunghi>
Component: Database-MigrationAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 0.10.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 7.0.0
Sentry Crash Report:

Description cfunghi 2010-01-01 17:20:27 UTC 
Version:           0.10.0-6.23 (using KDE 4.3.1)
OS:                Linux
Installed from:    openSUSE RPMs

I have about 22000 images managed in the former digikam3.db under OpenSuse 11.1 that contain a lot of image comments. I did set the option to store the image comments to the database as well as to the image exif data.
Then with the OpenSuse 11.2 I did migrate the digikam3.db to digikam4.db when I was using digikam the first time there. Now, some weeks later and another lots of data changes later - especially on the comments and geolocations - I found that it seems, I could not update image comments that are originally written in the digikam3.db. 
After recovering from this shock, I did investigate what's really stored in the digikam4.db and in the image data. Looking at the images with GwenView did show that all changed comments are stored in the image data. Then, looking at the database, the SQLite manager of Firefox did show duplicates in the ImageComments table for all images that had comments written under digikam3.db. And obviously there are updates made in one of the duplicate records, but not the one that is read to reflect the changes in the GUI of the comment control. To be more precise, the duplicates means the records refer to the same image, but have a unique record id
In other words, making a change on a comment written under digikam3.db does show: 
(1) former comment "My comment"
(2) change it now to "My comment new"
(3) after storing it shows again "My comment", but the new comment is stored in the image data and in one of the duplicate records.

For me now there is the question, how to get rid of these duplicates. I have more of 6000 of them, deleting them manually is just not fun. 
Another issue is, as these duplicates refer to the same image, but have a unique record id - so, which record can I delete, what happens after deletion, system crashes, more inconsistent data? 

Are there any suggestions to by-pass the problem or, more welcome, to repair the database by program?
Comment 1 caulier.gilles 2010-01-01 17:26:15 UTC 
If you have'nt remove your old digikam3.db file, remove new digikam4.db file and try to import again with digiKam 1.0.0 out few days ago. More than 450 bugs have been fixed since 0.10.0

Gilles Caulier
Comment 2 cfunghi 2010-01-01 17:41:07 UTC 
Thanks for the fast reply, but as I reported I did a lot of changes on my digikam4.db until I found this bug. Also I did search thoroughly for a report of this bug before I wrote this report. And therefor I'm afraid it was not detected before and is not solved.
Nevertheless I would like to do the test, but there is another issue on testing with the latest version: I'm not so much familiar with building the digikam from the sources. Is there a rpm package for OpenSuse that can be used?
Comment 3 Marcel Wiesweg 2010-01-01 17:46:31 UTC 
See comments 8 and 9 from bug 189080.
This is indeed an unfortunate bug, fixed for half a year now, but 0.10.0 is a year old.

*** This bug has been marked as a duplicate of bug 189080 ***
Comment 4 cfunghi 2010-01-01 18:00:28 UTC 
Yes, the bug 189080 reports exactly the issue I found. Thanks for the SQL string to get the duplicates rid.
Comment 5 caulier.gilles 2019-12-30 06:54:19 UTC 
Not reproducible with 7.0.0 beta 1.