Bug 308066

Summary: MySQL: How to delete data finally
Product: [Applications] digikam Reporter: Sabine
Component: Database-MysqlAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: wishlist CC: caulier.gilles
Priority: NOR    
Version: 2.6.0   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In: 7.5.0
Attachments: the requested debug trace

Description Sabine 2012-10-08 10:39:02 UTC 
I deleted photos with incorrect date/time from digikam. The corresponding entries in the database (MySQL) are not deleted, just the album is set to "null". How can I get rid of the unwanted data (i.e. how can I compress/reorganize the database)?

Furthermore the (in my case incorrect) data from the database is reused when I try to reimport the photos again. 

Is there a workaround (SQL-commands to "clean" the database)?

Reproducible: Always
Comment 1 caulier.gilles 2012-10-08 12:14:25 UTC 
Install 2.9.0, run kdebugdialog, and turn on digiKam debug space.

Run digiKam froma console andreport all debug trace when you try to delete an item.

Gilles Caulier
Comment 2 Sabine 2012-10-08 17:30:37 UTC 
Created attachment 74422 [details]
the requested debug trace

With digikam 2.9.0 the deleted images are still in the MySQL-Database, just the album is set to "null".
Comment 3 Marcel Wiesweg 2012-10-08 19:33:11 UTC 
The removed entries will definitely be deleted after a certain time (7-30 days).
Judging from 308065, you've already found the Read Metadata From Files to Database functionality to fix your problem?
Comment 4 Sabine 2012-10-09 06:23:20 UTC 
> The removed entries will definitely be deleted after a certain time (7-30 days).
What does it depend from? Can I change that setting?

> Judging from 308065, you've already found the Read Metadata From Files to Database functionality to fix your problem?
Yes, my immediate problem is solved.
Comment 5 Marcel Wiesweg 2012-10-10 18:52:18 UTC 
It's a hardcoded heuristic. If you have more complete scans in short time, the duration is less. The intention first and foremost not to lose data when files are moved (which can mean first deleted, then reappearing), and for situations were strange things happen and hard disks disappear. It gives a good fallback for a lot of things which may go wrong.

Btw, the SQL to clean up is very simple:
"DELETE FROM Images WHERE status=3;"

Closing as wontfix as we dont want to change the feature.