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

[bugzilla_noreply at kde.org]

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

caulier.gilles at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
   Version Fixed In|                            |5.4.0
      Latest Commit|                            |http://commits.kde.org/digi
                   |                            |kam/2183d3849f857ef1c04cf76
                   |                            |5fa357a211a8757d8
         Resolution|---                         |FIXED

--- Comment #25 from caulier.gilles at gmail.com ---
Git commit 2183d3849f857ef1c04cf765fa357a211a8757d8 by Gilles Caulier.
Committed on 22/11/2016 at 12:01.
Pushed by cgilles into branch 'master'.

Next stage to improve FuzzySearch management to apply patch #102381 from Mario
Frank

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.
FIXED-IN: 5.4.0

M  +19   -0    app/items/imageviewutilities.cpp
M  +1    -0    app/items/imageviewutilities.h
M  +63   -0    libs/album/albummanager.cpp
M  +10   -0    libs/album/albummanager.h
M  +17   -7    libs/database/dbjobs/dbjob.cpp
M  +21   -0    libs/database/dbjobs/dbjobinfo.cpp
M  +14   -6    libs/database/dbjobs/dbjobinfo.h
M  +36   -6    libs/database/haar/haariface.cpp
M  +16   -0    libs/database/haar/haariface.h
M  +17   -0    utilities/fuzzysearch/findduplicatesview.cpp
M  +1    -0    utilities/fuzzysearch/findduplicatesview.h
M  +20   -2    utilities/maintenance/duplicatesfinder.cpp
M  +3    -0    utilities/maintenance/duplicatesfinder.h

http://commits.kde.org/digikam/2183d3849f857ef1c04cf765fa357a211a8757d8

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