Digikam writes to various existing namespaces (configurable) and to its own one: Xmp.digiKam.TagsList (I don’t know whether that is an “official” notation or just one used in digiKam). Your proposal should work fine. I would do the manual intervention without digikam running (it scans on changes), otherwise it might get confused, and then run the maintenance job to update db from metadata.
There are two previous bug reports dating to 2011 and 2012 (268688 – Write metadata to all images does not remove obsolete tags, 309058 – Database can't be synchronized with XMP sidecars), but those have both been closed as fixed, which is why I decided to try using the latest version of digiKam for actually tagging images instead of just as a image browser.
368734 – Moving a hierarchy of tags (a tag with subtags) doesn't work and can lead to losing the complete hierarchy almost sounds as if only sqlite databases are affected by the inability to rearrange the tag tree. See comments 11 and 12 in the bug report.
Can anyone confirm that mysql databases are not affected? That rearranging the tag tree is possible to do when using mysql? Or did I misunderstand the bug report?
Thanks @rasimo! I was trying to convince the app image to write xmp tags last night so I could take a looks, but I was not successful.
I also wanted to use the internal mysql of the app image, but it couldn’t find mysqld. I’m using opensuse tumbleweed.
@elle, I’m willing to help script an xslt solution if you can provide some xmp files.
I moved a second level tag with one subtag to another root level tag. The moved tags were newly created without any images assigned to it. I get an error on the command line about not being able to prepare a statement, but the move persisted after a restart.
digikam.dbengine: Prepare failed!
digikam.dbengine: Failure executing query:
"LOCK TABLE Tags WRITE;"
Error messages: "QMYSQL3: Unable to prepare statement" "This command is not supported in the prepared statement protocol yet" 1295 2
Bound values: ()
Actually after trying this out I had another look at this bug report:
https://bugs.kde.org/show_bug.cgi?id=368734
There it is already reported that it works for mysql and doesn’t for sqlite, because of an SQL trigger that only works for a single tag but not for a tags tree. Probably mysql doesn’t use this trigger and thus does not suffer from the same problem. However the error above still makes it seem like not everything is just as it should be for mysql either.
Hi @rasimo - I’m a bit confused by what you said. Did the second level tag that you moved have any images assigned to it before you moved the tag?
After moving a tag branch to a new location, I would expect the image tags to follow the move. So all the images that originally had tags on the branch before the move, would still have the same tags after moving the branch. In other words, moving the branch should not just create new branch with no tags - that would mean all the original tagging was lost.
Hi @paperdigits - what is xslt? That is very, very kind of you to offer to help script an xslt solution. I can provide some xmp files, but it will take a few days to put together. Maybe in the meantime it will turn out that the answer is to switch from sqlite to mysql, though on the other hand that might be asking for a whole additional layer of problems . . .
XML Stylesheet Language - Transformations.
Argh, the far too frequent issue that I make long confusing sentences struck again (I am not native English speaker, but that’s a poor excuse). What I did was the following: First I created a new second level tag and one additional child tag. I did not assign these tags to any images. Then I moved the new second level tag together with it’s child to another top level tag. This move produced the command line output I posted earlier. Then I restarted digikam and the two tags I moved remained at the new position.
So I repeated the same procedure but now I first assigned the tags to be moved to some random images. Again the move persisted. However I can also confirm that it does not change the tags in the image metadata - which clearly is a bug. This can easily be resolved by either writing the image metadata to file or using the maintenance tool - nevertheless it is definitely a bug in itself.
And I can say that I am using internal mysql for a long time now and didn’t have problems (which doesn’t have to mean anything, that I use just a subset of the functionality present).
EDIT:
I couldn’t find any existing bug about metadata adjusting yet, I will open it.
The mysql error I posted before is: 383326 – Moving a tag does not update the parent tag correctly
EDIT2:
File the issue about moved tag not being applied to file metadata: 386224 – Metadata is not updated when moving tags
@elle, xslt is a templating language that is XML aware, more or less. So I can read in XMP files, which are XML, manipulate the structure or content of the XMP tag.
XSLT generally runs using java and the Saxon library.
Yes, that’s the way I read it as well. Thanks to @rasimo for testing it! I haven’t yet tried mysql for the database as it’s still labeled “experimental” but it seems that the risks are small, so I might give it a try when I get a chance.
@rasimo - thanks! for filing the bug report and for testing with a tag tree that had images assigned. As soon as I finish organizing my image files (a task independent of digiKam), I’ll try making a mysql database.
Does it matter if one uses mariadb or mysql? Neither is currently installed on my computer. I’m not even sure if mariadb is still around, come to think of it.
I am by no means an expert, but from what I read mariadb is the more actively maintained/progressive/free variant of mysql. At least it is what I have on my system and I think it also is the default for debian.
mySQL = property of Oracle. Oracle is slowly killing it.
mariaDB = fork of mySQL before oracle got it.
mariaDB is a drop in replacement for mySQL and receives much of the development efforts now.
Thanks! @rasimo and @paperdigits - It’s been years since I bothered to install any database besides sqlite. So “mariadb vs mysql” was just a dim memory of having read “something” a long time ago. The wikipedia article on mariadb gives a good summary, sounds like they took all the real developers with them when they forked from mysql when oracle took over. So mariadb it will be.
Oracle has used its corporate efficiency to kill everything sun had built. 
I installed mariadb. The next question is how does one use mariadb instead of sqlite with digiKam. Can anyone outline the steps or provide a link to a recent and still valid “how to”?
I did a quick internet search, and all the suggested pages seemed to be about earlier versions of digiKam. One of the articles gave a “must have this” qt library, that isn’t even in gentoo portage, at least not under any library name that I could find with repeated equery searches using wildcards. A lot has changed with KDE between KDE4 and KDE5.
Settings > database migration. Change only options in the right hand panel.
Hmm, that sounds easy, except I can’t find “Settings > database migration”. Is it under “Settings/Configure digiKam”? Or is a top-level option under Settings? Either way, I don’t see it (which doesn’t mean it’s not there). If it matters, I’m using digiKam 5.7.0.
Oh, now I feel silly. I didn’t reset a Gentoo use flag to actually use mysql - I set those use flags a long time ago. I bet as soon as I change the use flag to actually use mysql and recompile, there will be an option to use mysql. 
1 Like
It should be right above “configure digikam” in the settings menu
Also did you see that the digikam wizard Maik has committed a patch that should solve the problem with moving tag trees in sqlite? The change looks ridiculously small and I didn’t try out myself (I use mysql), but coming from Maik, I am pretty confident that it works.