Bug 141037 - Search using Tag Name does not work
Summary: Search using Tag Name does not work
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Advanced (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-02 01:18 UTC by Geoff King
Modified: 2017-08-18 09:39 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Geoff King 2007-02-02 01:18:11 UTC
Version:           0.9.1-svn (using KDE 3.5.5, Kubuntu (edgy) 4:3.5.5-0ubuntu3)
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.18.2

I try to do an Advanced Search using:
'Tag Name' 'Does Not Contain' and 'examplename'

Tags with "examplename" are included.
Comment 1 Geoff King 2007-02-13 02:04:43 UTC
This 'Does Not Contain' search fails when the image has multiple tags. 

When the 'Does Not Contain' search is done on an image with ONE tag, it works.  
Ex. Search for (Tag Does Not Contain "Dog") and the file only has "Dog" tag, it is not displayed.

When the same search (Tag Does Not Contain 'Dog') is done on an image with two or more tags such as "Dog" and "Max", the image is displayed and it should not be.

Hope this helps.
Comment 2 Arnd Baecker 2007-09-07 18:19:11 UTC
Thanks for the good analysis, in particular #1 is helpful
because it appears so puzzling at first ;-):

I have set up a test for this with 3 images in an Album named
`DoesNotContain` with tags association
   Image1.jpg  Tag1   TagBoth
   Image2.jpg  Tag2   TagBoth
   Image3.jpg         TagBoth

For a search,
  "Album Name" "Contains" DoesNotContain"
  as well as
  "Tag Name"   "Does Not Contain" "TagBoth
Image1 and Image2 appear, but no image should be shown

The query send to the sql database is:

SELECT Images.id, Images.name, Images.dirid, Images.datetime,
Albums.url FROM Images, Albums LEFT JOIN ImageProperties ON Images.id
= Imageproperties.imageid WHERE 
(  (Images.dirid IN (SELECT id FROM Albums WHERE url LIKE '%DoesNotContain%'))
  AND  
   (Images.id IN   (SELECT imageid FROM ImageTags WHERE tagid IN
           (SELECT id FROM Tags WHERE name NOT LIKE '%TagBoth%')))  
)  
AND (Albums.id=Images.dirid);

Let my try to analyze this (with my limited sql understand ...):
the expression in () after the first AND 
gets all the ids of tags whose name is not like a given
string. Then it gets all imageid's to which any of these tags
is associated.
Clearly this means that all images which have a different tag
are also included.

OK, that was the easy part.
The logic puzzle is now to construct a better query.
First attempt: 

   (Images.id IN   (SELECT imageid FROM ImageTags WHERE tagid NOT IN
           (SELECT id FROM Tags WHERE name LIKE '%TagBoth%')))  

This should get the tag id's of all tags which are similar to
"TagBooth". Then it should select all imageids for which 
ImageTags are not in that list of all tags.
Hmm, not sure if this will work.

Marcel? ... ;-)

BTW: could other searches be affected from the underlying problem as well?
Comment 3 Marcel Wiesweg 2008-01-16 21:58:12 UTC
Look at this:
For the key "TAG", in subQuery() there are four cases handled distinctly. I assume the same should be done with "TAGNAME" as well.
Comment 4 Marcel Wiesweg 2008-02-19 19:27:54 UTC
SVN commit 777086 by mwiesweg:

Backport SQL from 0.10 branch, now it is in analogy to the "TAG" search field above.
I think this fixes 141037.

CCBUG: 141037


 M  +24 -4     digikamsearch.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=777086
Comment 5 Arnd Baecker 2008-02-19 22:33:45 UTC
Great: I just checked the example in c#2 and now it works as expected.
Comment 6 Geoff King 2008-02-20 03:26:30 UTC
Seems to be fixed. Thanks.
Comment 7 Arnd Baecker 2008-02-20 06:42:26 UTC
Geoff, thanks a lot for the feedback (and again for the good analysis
at the beginning!).

Best, Arnd