Bug 308066 - MySQL: How to delete data finally
Summary: MySQL: How to delete data finally
Status: RESOLVED INTENTIONAL
Alias: None
Product: digikam
Classification: Applications
Component: Database-Mysql (show other bugs)
Version: 2.6.0
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-08 10:39 UTC by Sabine
Modified: 2022-01-14 14:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Attachments
the requested debug trace (7.40 KB, application/octet-stream)
2012-10-08 17:30 UTC, Sabine
Details

Note You need to log in before you can comment on or make changes to this bug.
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.