feat: make photo title searchable (any_text + title: prefix) - #1162
Open
cat101 wants to merge 2 commits into
Open
feat: make photo title searchable (any_text + title: prefix)#1162cat101 wants to merge 2 commits into
cat101 wants to merge 2 commits into
Conversation
Owner
|
Thanks! please add the new filed to the content wrapper also with proper alias. Also please merge as I did some significant changes to the search manager recently |
added 2 commits
June 7, 2026 21:03
Photo titles (Xmp.dc.title / IPTC ObjectName / Headline / acdsee caption) are extracted by MetadataLoader and stored on media.metadata.title, but the SearchManager never consulted that column — so titles set in digiKam et al. were loaded into the DB and shown in the info panel but invisible to search. This adds a SearchQueryTypes.title text-search type alongside the existing caption/file_name/etc., wires it into: - SearchManager (autocomplete + where-builder, mirroring the caption clause) - SearchQueryParser (title: prefix, parse + stringify) - AutoCompleteItemsPerCategoryConfig.title (default 3, mirroring caption) - frontend EnumTranslations + autocomplete icon any_text now also matches media.metadata.title, fixing the original bug (plain words don't find photos by title). Tests: - SearchQueryParser round-trip for title type - SearchManager 'as title': explicit title:Shuttle + bare any_text:Shuttle - TestHelper getPhotoEntry2 gets metadata.title = 'Shuttle' as the fixture
Wrap the title LIKE clause in a Brackets predicate that also matches 'media.metadata.title IS NULL' when the query is negated. Without this, photos with no title (the common case) are excluded from negated any_text results because NULL NOT LIKE 'x' evaluates to NULL (three-valued logic), which fails the AND-chain that negation builds. Mirrors the existing pattern used for array fields (keywords/persons) at matchArrayField — text-typed sparse fields need the same treatment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As with my other PRs, this has been generated using AI. This one is really a small missing feature. I have manually tested it on my environment.
Problem
Photo titles (
Xmp.dc.title/IPTC ObjectName/Photoshop Headline/acdsee.caption) are extracted byMetadataLoader.mapTitleand stored onmedia.metadata.title— butSearchManagernever consults that column. Titles set in digiKam et al. are loaded into the DB and shown in the info panel (added in #798), yet are invisible to search: a bare word in the search box doesn't find them, and there's notitle:prefix.Reproducer: tag a photo with title "Shuttle" in digiKam → re-index → search "Shuttle" → no results.
Fix
Add a
SearchQueryTypes.titletext-search type alongside the existing caption / file_name / etc., wired into:media.metadata.title, mirroring the existingcaptionclause. The negated branch wraps the predicate in aBracketsthat also matchesIS NULL, since title is sparse andNULL NOT LIKE 'x'is NULL under three-valued logic (would otherwise drop untitled photos from negatedany_textresults).titleinQueryKeywords+defaultQueryKeywords('title') + stringify switch. Parsing auto-picks up the prefix because it iteratesTextSearchQueryTypes.3) — matches caption.EnumTranslationslabel + autocomplete icon (reusesionTextOutline).any_textnow also matchesmedia.metadata.title, fixing the original bug. The DB schema already has thetitlecolumn (added in #798), so no migration is required.Tests
SearchQueryParserround-trip fortitletype.SearchManager— newit('as title'): asserts bothtitle:Shuttle(explicit) andany_text:Shuttle(the bug fix) return the seeded photo.TestHelper.getPhotoEntry2(sw2.jpg) getsmetadata.title = 'Shuttle'. Picked because "Shuttle" contains no substring exercised by existing autocomplete assertions (tat,star,wars,phantom,arch,wa,a,sw,han) so no other test had to be updated.Notes
IS NULLhandling in the negate branch is a stricter pattern than the existingcaptionclause uses — caption has the same latent NULL bug, but I left it alone to keep the diff minimal and focused. Happy to file a follow-up if you want it normalized.$localize\Title``). The .xlf translation files would need a follow-up pass.