[digikam] [Bug 261417] Duplicate image counter is not adjusted when removing a duplicate

[Mario Frank]

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

--- Comment #22 from Mario Frank <mario.frank at uni-potsdam.de> ---
Okay, I looked for other ways to signal the AlbumManager about the deleted
images and I did not find performant ways to do this in another way.

Thus, I will upload the patch. Here is the commit message:
"[PATCH] This commit fixes bug 261417. When images are deleted, the
 ImageViewUtilities give the ImageInfos to the DIO. In the ImageViewUtilities,
 the ids of the deleted images are buffered in a list and given to the
 AlbumManager via Signal-Slot-communication. I do that since in database
 layer, only the URIs of the images are present and getting the image ids is
 unnecessary effort. Since the AlbumManager already has all SAlbums, it is
 easy to first get all SAlbums that represent DuplicateSearches (I implemented
 a method to get all SAlbums by type) and then get all those albums that
 contain the deleted images (SearchXmlReader is needed here).

In order to have a good performance and do no unnecessary work, the
AlbumManager unites
all image ids from the SAlbums to update and subtracts the ids of the deleted
images (set operations).
This way, I am able to communicate the set of images to rescan to the
FindDuplicatesView.
Before notifying the FindDuplicatesView, I delete all SAlbums that should be
updated.
The reason: Consider an SAlbum that contained two duplicates - the original
image and the now deleted
image. If I start a normal duplicates search, no SAlbum will be created for the
original image and
the SAlbum will thus not be updated and should not be in the final result set.

Since I now know the ids of the images to rescan, I notify the
FindDuplicatesView.
But now I do not have albums to search in - and in fact this would not really
be performant since
uninvolved images would be scanned. Thus, I extended the DuplicatesFinder with
a new constructor
for searching for duplicates in a set of images. This could be applicable in
other situations, too.
To make this work, I extended the DB-Jobinfo with a switch for update of
duplicates where the
set of images is and not the albums and tags is used for duplicates search.
This way, I can set the
image ids and the update flag in the job info. The DBJob triggers a new variant
of rebuildDuplicates
in haariface where the image ids are taken directly.

With this approach, only the SAlbums that need to be updated are updated.
SAlbums are only lost,
if no duplicates exist due to deletion which is appropriate. Previously not
existing SAlbums cannot be created
since no new images are involved.
"

By the way, I found some flaw that can lead to an unexpected set of SAlbums.
I'll open another file soon.

Cheers,
Mario

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