Not sure, if what I'm describing is a bug or simply not possible due to some aspect of how tags are stored internally. What I'm trying to do is the (to me) simple task of reorganizing the tag hierarchy. To give a simple example, do the following: 1. Open Digikam 2. Open the tag manager 3. Click any tag and drag-and-drop it to under another tag 4. Close the tag manager 5. Close Digikam 6. Re-open Digikam Upen re-opening Digikam the tag that was moved should still be under the new tag, shouldn't it? At least that's what I would expect. But that is not what is happening. The procedure described above only seems to work for single tags without subtags. When trying to move a tree of tags (e.g. a tag with a subtag), however, nothing seems to change in the database at all: The tag-tree does appear to be filed under the new tag only for the moment - upon re-opening Digikam, however, the changes are reverted and the tags are back where they were before. Note: It's possible to completely lose a huge number of tags by this procedure (this happened to me), when whole tag trees are moved and then the original (now seemingly empty) root tags are deleted. Upon re-opening Digikam those root tags are gone, of course, but the tag trees that were moved before have disappeared as well and can't be resurrected. By the way: This seems to be a long-standing issue. The problem was present in version 4.12 and is still unresolved in 5.1. Reproducible: Always Steps to Reproduce: 1. Open Digikam 2. Open the tag manager 3. Click any tag that has subtags and drag-and-drop it to under another tag 4. Close the tag manager 5. Close Digikam 6. Re-open Digikam 7. Check the tag manager. Actual Results: After re-opening Digikam the changes to the tag trees (tags with subtags) are reverted: The tags are back where they were before moving them. Expected Results: After re-opening Digikam the re-organized tag trees (tags with subtags) should keep their new position in the hierarchy. The problem appears on Linux (not sure about other plattforms) in every configuration I tried (with or without "lazy synchronization", with or without writing to sidecars etc.), was present in version 4.12 and is still present in 5.1.1.
Which database type do you use ? Gilles Caulier
I didn't change the default that was defined by the software, i.e. SQLite. Would you suggest I try a different one? Marcus
No. Sqlite is fine and stable. Now, i would to know ALL metadata setup option used for. Gilles Caulier
I suppose you mean the options that are activated for metadata in the preferences. Okay... the following options are currently ticked in Configure > Metadata > Behavior (I also tried other configurations, but not all combinations, of course): Behavior: Image Tags Captions and Title Metadata templates Use lazy synchronization Read from sidecar files Write to sidecar files (Write to image and XMP Sidecar) All other options are deactivated. My database is on a local disk, by the way. Oh, now that I think of it... I upgraded from 4.12 to 5.1 recently, without creating a new database. Do you think, that might have something to do with the problem?
yes : 1/ Use lazy synchronization 2/ the options about XMP sidecar. Gilles Caulier
Alright, thanks. Creating a new database shouldn't be a problem. However... Is there a way to transfer my tag hierarchy (a controlled vocabulary containing hundreds of tags) from the old database to the new one?
Hmm, I now removed the old database files and let Digikam create new ones. Same problem! Should I also deleted the configuration directory?
- Removed all configuration files, and all databases. - Started from scratch (version 5.1) and let Digikam import the files in one directory tree. - Changed nothing in the configuration. - Opened the tag manager and moved one tag that contained a subtag to another location in the tree. - Tagged one of the images with the tag that I had just moved. - Closed Digikam. - Opened Digikam: The image is tagged correctly, but the tag is back in the old location in the tree.
The problem still present because the wrong hierarchy was saved in image metadata (XMP) At start up, even if database is empty, whole hierarchy is recreated using file metadata. If you want to find which metadata option is to origin of the problem, you need to use fresh image not yet tagged. Gilles Caulier
Thanks for your help. Ok, so I removed literally *everything* (configuration files, databases etc.) that had to do with digikam (version 5.1) and started with a fresh install. - Started digikam. - digikam asked me for the directory, where I keep me images. I chose a directory that contained a few PNG files that have never been in contact with any version of digikam before. - I kept the rest of the options at their default, i.e. did not change anything. - Once digikam had started up, I immediately opened the Tag Manager. - I created two top-level tags. - I then created two subtags for one of the top-level tags. - I closed digikam. - I opened digikam again. - I opened the Tag Manager again. - I moved the top-level tag that contained the two subtags to under the other top-level tag. digikam asked me, if I wanted to "move here". I clicked OK. - I closed digikam. - I opened digikam again. - The changes are reverted! The top-level tag that I moved is back where it was. Can you reproduce this? Is there anything else that I can try?
Any news on this? Can anyone confirm the phenomenon that I'm describing?
(Using, digikam 5.2.0) What I did: 1)Drag tags(with sub tags) under another tag. 2)Restarted digiKam. This seems to not be reproducible for me.(For QMYSQL) The moved tags are still in the new location.The changes are visible even in the database tables. But, I confirm the report for SQLite. After restarting digiKam, neither the moved tags remains in the new location, nor the changes are visible in the database.
Swati, the problem is this trigger in the SQLite DB. It only works with one tag, not with a tags tree. <statement mode="plain">CREATE TRIGGER move_tagstree UPDATE OF pid ON Tags BEGIN DELETE FROM TagsTree WHERE ((id = OLD.id) OR id IN (SELECT id FROM TagsTree WHERE pid=OLD.id)) AND pid IN (SELECT pid FROM TagsTree WHERE id=OLD.id); INSERT INTO TagsTree SELECT NEW.id, NEW.pid UNION SELECT NEW.id, pid FROM TagsTree WHERE id=NEW.pid UNION SELECT id, NEW.pid FROM TagsTree WHERE pid=NEW.id UNION SELECT A.id, B.pid FROM TagsTree A, TagsTree B WHERE A.pid = NEW.id AND B.id = NEW.pid; END;</statement> Maik
(In reply to Maik Qualmann from comment #13) > Swati, > > the problem is this trigger in the SQLite DB. It only works with one tag, > not with a tags tree. > > <statement mode="plain">CREATE TRIGGER move_tagstree UPDATE OF pid ON Tags Is this because only one pid is written in this UPDATE query? I think we should include all the pids for handling Tags Tree? > BEGIN > DELETE FROM TagsTree > WHERE > ((id = OLD.id) > OR > id IN (SELECT id FROM TagsTree WHERE pid=OLD.id)) > AND > pid IN (SELECT pid FROM TagsTree WHERE id=OLD.id); > INSERT INTO TagsTree > SELECT NEW.id, NEW.pid > UNION > SELECT NEW.id, pid FROM TagsTree WHERE id=NEW.pid > UNION > SELECT id, NEW.pid FROM TagsTree WHERE pid=NEW.id > UNION > SELECT A.id, B.pid FROM TagsTree A, TagsTree B > WHERE > A.pid = NEW.id AND B.id = NEW.pid; > END;</statement> > > Maik
new 5.6.0 pre-release as bundle is available here : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Please check if this problem still reproducible with these versions. Thanks in advance Gilles Caulier
I just ran into this problem on 5.6.0.
Git commit b70da4cf70b2824d5e2371c0ceb118863e65910a by Maik Qualmann. Committed on 01/11/2017 at 21:32. Pushed by mqualmann into branch 'master'. fix moving tags with subtags and SQlite DB FIXED-IN: 5.8.0 M +2 -1 NEWS M +11 -2 libs/database/coredb/coredb.cpp https://commits.kde.org/digikam/b70da4cf70b2824d5e2371c0ceb118863e65910a