Bug 113915 - Tags are lost after "Save As..."ing.
Summary: Tags are lost after "Save As..."ing.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ImageEditor-Save (show other bugs)
Version: 0.8.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-05 21:43 UTC by Tung NGUYEN
Modified: 2022-02-03 03:49 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tung NGUYEN 2005-10-05 21:43:28 UTC
Version:           0.8.0-beta2 (using KDE KDE 3.4.2)
Installed from:    Compiled From Sources
OS:                Linux

TEST 1:
======
- In Album1, open Photo1, which has tag T1, with the DigiKam Image Editor.
- In the Image Editor, "Save As..." Photo1 as Photo2 in the same album Album1.
- Quit the Image Editor and reopen Photo1 with it.
- "Save As..." Photo1 as Photo3 in the same album Album1.

=> Photo3 has lost his tag T1 and I have in Konsole:

digikam: Saving to :/home/anonyme/Dossiers personnels/Photos/Album1/OCjKba.tmp (jpeg)
digikam: WARNING: sqlite_step error: columns imageid, tagid are not unique on query: INSERT INTO ImageTags (imageid, tagid)
SELECT I.id, T.tagid FROM Images AS I, ImageTags AS T WHERE
     I.id=(SELECT Images.id FROM Images WHERE
           dirid=17 AND name='Photo 003.jpg')
AND  T.tagid IN (SELECT tagid FROM ImageTags WHERE
                   imageid=(SELECT id FROM Images WHERE
                             dirid=17 AND name='Photo 001.jpg'))
digikam: Dirty: /
digikam: Dirty: /Album1

=> Sometimes (in another tests), Photo2 can lose his tag T1 too and I have the same Konsole message.

TEST 2:
======
- In Album1, open Photo1, which has tag T1, with the DigiKam Image Editor.
- In the Image Editor, "Save As..." Photo1 as Photo2 in a different album Album2.

=> Photo2 has lost his tag T1 and I have in Konsole:

digikam: Saving to :/home/anonyme/Dossiers personnels/Photos/Album2/et7jAa.tmp (jpeg)
digikam: WARNING: sqlite_step error: columns imageid, tagid are not unique on query: INSERT INTO ImageTags (imageid, tagid)
SELECT I.id, T.tagid FROM Images AS I, ImageTags AS T WHERE
     I.id=(SELECT Images.id FROM Images WHERE
           dirid=1 AND name='Photo 002.jpg')
AND  T.tagid IN (SELECT tagid FROM ImageTags WHERE
                   imageid=(SELECT id FROM Images WHERE
                             dirid=17 AND name='Photo 001.jpg'))
digikam: Dirty: /
digikam: Dirty: /Album2
Comment 1 caulier.gilles 2006-04-03 16:19:18 UTC
Tung, can you reproduce this problem with current implementation from trunk branch (0.9.0-svn) ?

Gilles Caulier
Comment 2 Marcel Wiesweg 2006-04-12 23:53:26 UTC
SVN commit 529254 by mwiesweg:

digikam from trunk:

The ImageEditor can now access the database independently
from main view, i.e. also if main moved to a different directory.

- adjust ImageInfo to be more like a database item wrapper class
- add a method to ImageWindow to start it with a list of
  ImageInfo objects, use this in AlbumIconView
- adapt ImageWindow to (optional) ImageInfo list
- adjust behavior of saveAsIsComplete
- add itemChanged methods to ImagePropertiesSidebarDB:
  - one takes only a URL (no database)
  - one takes an ImageInfo object (used by ImageWindow, full DB support)
  - one takes AlbumIconItem and -View (used by main view,
    full DB support, optional future interaction with the view)
- ImageDescEditTab now works on an ImageInfo object
- add a copyItem method to ImageInfo as a wrapper for said function from AlbumDB
- modify AlbumDB::copyItem to return image id of inserted image
- add DISTINCT keyword to second SELECT statement of AlbumDB::copyItem.
  With all of above changes, I constantly produced bug #113915.
  I do not know why the SELECT statement produces (in my case) three times
  the same result so that INSERT complains, and I do not know which of
  my changes should ever trigger this problem, but the DISTINCT fixes this.
  If anyone speaks SQL, you might want to check my comment in AlbumDB::copyItem.

Currently, the rating is not copied when database information is copied (in copyItem).
Should this be done?

CCBUG: 113915
CCMAIL: digikam-devel@kde.org



 M  +19 -4     digikam/albumdb.cpp  
 M  +5 -3      digikam/albumdb.h  
 M  +17 -10    digikam/albumiconview.cpp  
 M  +2 -2      digikam/digikamview.cpp  
 M  +31 -0     digikam/imageinfo.cpp  
 M  +22 -7     digikam/imageinfo.h  
 M  +33 -35    libs/imageproperties/imagedescedittab.cpp  
 M  +13 -12    libs/imageproperties/imagedescedittab.h  
 M  +52 -22    libs/imageproperties/imagepropertiessidebardb.cpp  
 M  +22 -14    libs/imageproperties/imagepropertiessidebardb.h  
 M  +105 -70   utilities/imageeditor/editor/imagewindow.cpp  
 M  +12 -6     utilities/imageeditor/editor/imagewindow.h  
Comment 3 Marcel Wiesweg 2006-06-03 18:53:07 UTC
Meanwhile properties are copied as well. Compared to the original post, the AlbumDB::copyItem method has been rewritten so that the SQL problem should no longer be possible. Closing this bug.