tagging modules : search on sub-level of hierarchical tag is not working
On the tagging modules, Hierarchical tag are working great, like "photo|friend|dave"
We can search existing tag via tape the begin of the word (like "pho").
But it doesn't search on sub-level of hierarchical
So trying to find "dav" is not working, actually to search it, we need to enter "photo|friend|dav" for example.
It's can be annoying when manage lot of hierarchical tags.
#4 Updated by Tobias Ellinghaus over 6 years ago
- % Done changed from 0 to 20
- Status changed from Closed: invalid to Triaged
Since this issue is not about collection but the tagging module I am reopening. This would need some GDK/GTK magic to allow this kind of searching for the autocompletion (I guess that's what you are talking about?).
#6 Updated by Christian iuga over 6 years ago
Alexander Wagner make a analyse about this situation (he send a mail on the dartable user list, subject : "Adding tags / Substring search" ) :
i have make a patch whis he's recommandation, it's working for me.
He fixed it on the tagging module but not on the pop-up when used Ctrl-T ( need your help about it ) :
As the current tagging of dt does not work as I expect it I played a bit
in common/tags.c, mainly dt_tag_get_suggestions().
Actually, from l.495 I would expect, that as soon as I type a tag it is
searched in the internal list of tags and, as the sql is, this is
actually the substring search I was expecting to happen. However, it
doesn't work that way in the GUI.
So I digged a bit further and there comes this magic with the tagxtag
table. I admit that I do not entirly understand what's going on there,
but as far as I understand it the notion is that it should do a sorting
of suggestions by means of "this tag most likely implies that tag". As I
understand it it's based on bean counting: 1x2 = 56 times, 1x3 = 7 times
and so on, so tag 2 would rank higher than tag 3.
If I remember correctly, this was there way before hierarchical tags
were implemented, and as it really screws up my suggestion list, I
wonder if this is just not playing nicely with keyword chains. At least
as far as I get it it doesn't live on a chain at all but on individual
tags. Also, it seems that it's suggestions are somewhat sensitive to the
initial loading of the tagxtag table, and in my case I found a bunch of
strange values there, though I ingested my whole collection and dt
should have seen all tags by that means and I'd expect therefore this
table to be initialized as it should.
Anyway, point is, as soon as I comment l.495 to l.531 and just use the
"SELECT name, id FROM tags T WHERE T.name LIKE '%%%s%%' ",
DT_DEBUG_SQLITE3_PREPARE_V2( dt_database_get(darktable.db), query,
-1, &stmt, NULL);
instead, my suggestion list looks like expected and I get this substring
like search I mentioned in my other mail. (Ie. keying in "red" suggests
Still, it is not suggested in the popup menu (in fact the pop up menu
doesn't appear at all), but at least in the list below below the entry
field. I did not yet fiddle out how the popup menu gets populated. It
seems unrelated to the list widget. In fact I think it was also invented
later on and there seems to be some inconsistency.
Any ideas on that front?
#7 Updated by Christian iuga over 6 years ago
- % Done changed from 20 to 70
- Status changed from Triaged to Patch attached
- File 0001-Resolve-the-bug-9088-by-change-to-order-of-sql-form-.patch 0001-Resolve-the-bug-9088-by-change-to-order-of-sql-form-.patch added
I have found how to fix the bug :
Actualy how it's done :
- SELECT T.id FROM tags T WHERE T.name LIKE '?1'; --> into temp table * SELECT TXT.id2 FROM tagxtag TXT WHERE TXT.id1 IN (temp table) * AND TXT.count > 0 ORDER BY TXT.count DESC; * SELECT TXT.id1 FROM tagxtag TXT WHERE TXT.id2 IN (temp table) * AND TXT.count > 0 ORDER BY TXT.count DESC; * * SELECT DISTINCT FROM tags T JOIN memoryquery MQ on MQ.id = T.id ORDER BY T.id;
We have to change the order by on the last command.
It's actualy ordered by id AND dt_tag_get_suggestions suggest all hierchical tag at they are all linked on the tagxtag database ....
( we should also put a LIMIT ? )