[Digikam-devel] [digikam] [Bug 363697] Album visible even after deletion

[Johannes Hirte via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363697

--- Comment #8 from Johannes Hirte <johannes.hirte at datenkhaos.de> ---
(In reply to Johannes Hirte from comment #7)
> Of course, foreign key checks is part of the problem. Disabling this with:
> 
>     d->db->execSql(QString("SET FOREIGN_KEY_CHECKS = 0;"));
>     d->db->execSql(QString("UPDATE Albums SET albumRoot=0, relativePath=?
> WHERE id=?;"),
>                    newRelativePath, albumID);
> 
>     // for now, we make no distinction to deleteAlbums wrt to changeset
>     d->db->recordChangeset(AlbumChangeset(albumID, AlbumChangeset::Deleted));
>     d->db->execSql(QString("SET FOREIGN_KEY_CHECKS = 1;"));
> 
> will make deletion of albums work. But I'm not sure, if this is really the
> right way to fix this.

Okay, this won't work as mysql and sqlite have different ways for
disabling/enabling foreign key checks.

The real problem is, that Albums.albumRoot has to be set to a value that
doesn't exists in AlbumRoots. The two options I see for solving this:

1) working with a fake album in AlbumRoots, so all albums that should be
deleted can be set to this fake album

2) disable foreign key checks for this operation. This has to be done in a
generic way disableForeignKeyCheck()/enableForeignKeyCheck() that implements
the specific part for every DBMS
for MySQL: "SET FOREIGN_KEY_CHECKS = 0/1;"
for sqlite: " PRAGMA foreign_keys = OFF/ON;"

-- 
You are receiving this mail because:
You are the assignee for the bug.