Bug 368734

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