GNOME Bugzilla – Bug 765981
fts warning from tracker when searching for files with "-" in name
Last modified: 2016-05-11 15:37:10 UTC
when searching for a file with the open-file dialog, such as "ide-" I get the following warning from the tracker backend: GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: fts5: syntax error near "-"
This is mostly because tracker hasn't traditionally done much effort to wrap/simplify the FTS syntax, which has been largely refurbished in FTS5: https://www.sqlite.org/fts5.html#section_3 FTS3/4 had a quite more minimalistic syntax by default, which also didn't propagate syntax errors up the sql machinery. It was generally friendlier with search-as-you-type UIs. I however think this is better handled in the users of fts:match, the full query syntax might be useful in apps. That unfortunately means some tokenizing should be done when composing the query. I see two approaches that might apply here, depends on whether we considered globbing a feature here or not. Let's say we enter "ide- foo bar*" in the entry, we currently do: ... MATCH "ide- foo bar*" : the '-' raises the exception, the '*' is interpreted as expected though So we could do: ... MATCH "\"ide- foo bar*\"" : all three tokens are interpreted as a "phrase", so they go through the tokenizer, 'ide-' and 'bar*' go through the tokenizer, which doesn't trigger neither the syntax error nor globbing. Or we could try to tokenize each word separately keeping the '*' out, so it turns out: ... MATCH "\"ide-\" \"foo\" \"bar\"*" : this lets the '-' go through the tokenizer, and allows per-term globbing I guess a mixed approach could be made too if we only allow one trailing '*'. I'm attaching first a patch that implements the simplest option.
Created attachment 327295 [details] [review] searchenginetracker: Quote fts match so it's seen as a single phrase FTS5 has a complex enough syntax that it makes not much sense to wrap in simple search boxes.
While I can't really comment on the ultimate design goals, I do think it makes sense to do a bit more processing client-side. The patch also does fix my type-ahead issue.
I don't think we want to interpret globs (or regexps) in these strings. If we want more expressive search, that would probably have some explicit ui (e.g. to select 'exact match' or 'prefix only')
*** Bug 765919 has been marked as a duplicate of this bug. ***
(In reply to Matthias Clasen from comment #4) > I don't think we want to interpret globs (or regexps) in these strings. If > we want more expressive search, that would probably have some explicit ui > (e.g. to select 'exact match' or 'prefix only') Good, exactly my sentiment. I'm pushing the patch then.
Attachment 327295 [details] pushed as 27c1cce - searchenginetracker: Quote fts match so it's seen as a single phrase
*** Bug 765703 has been marked as a duplicate of this bug. ***
*** Bug 766282 has been marked as a duplicate of this bug. ***