GNOME Bugzilla – Bug 782596
tracker query gives no results when search entry is empty
Last modified: 2017-05-16 21:00:03 UTC
See patch.
Created attachment 351781 [details] [review] search-engine-tracker: don't use fts:match on empty search entry If the search entry is empty and filtering for date or mime type is added, then the sparql query always returns nothing because of fts:match '""*' To get the expected search results don't use fts:match when the search text is empty.
Review of attachment 351781 [details] [review]: Makes total sense! I found a couple of nitpicks though. ::: src/nautilus-search-engine-tracker.c @@ +331,3 @@ " nie:url ?url;"); + if (g_strcmp0 (search_text, "") != 0) g_strcmp0(NULL, "") will be != 0, which might include the very awkward '"(null)"%' search term :). At first sight I didn't see anything ensuring search_text is non-NULL, although otherwise the g_utf8_strdown/tracker_sparql_escape_string calls would warn, so this case is unlikely. However, I think it is clearer to check the first byte of the string: if (*search_text) or: if (search_text[0] != '\0') if you like it verbose. @@ +333,3 @@ + if (g_strcmp0 (search_text, "") != 0) + { + g_string_append_printf (sparql, " fts:match '\"%s\"*';", search_text); I think you should not move the semicolon from the line adding the nie:mimeType relationship to this one. Now if you get a query with search term, but no mimetype(s), you'll end up with the semicolon at the end of the property-object list, which is not valid according to sparql grammar: https://www.w3.org/TR/rdf-sparql-query/#rPropertyListNotEmpty Sparql is quite picky here, so graphs must be unambiguously complete, the only separator allowed at the end is the triple separator '.'.
Created attachment 351793 [details] [review] search-engine-tracker: don't use fts:match on empty search entry If the search entry is empty and filtering for date or mime type is added, then the sparql query always returns nothing because of fts:match '""*' To get the expected search results don't use fts:match when the search text is empty.
Hmm, I see why you were trying to shuffle the semicolons around... If the triggered search contains no mimetype and no search term string, the produced sparql will still be incorrect. Let me suggest moving the semicolon from the last "nie:url ?url;" property right above search term handling into the beginning of the fts:match substring itself, this way the produced sparql will be correct regardless of the paths taken: "... nie:url ?url" + "; fts:match '...'" + "; nie:mimeType ?mime" + ". FILTER (...)" "... nie:url ?url" + "; fts:match '...'" + ". FILTER (...)" "... nie:url ?url" + "; nie:mimeType ?mime" + ". FILTER (...)" "... nie:url ?url" + ". FILTER (...)" Probably this condition of no search term and no mimetype is quite unlikely, but IMHO results in a simpler patch, and more similar to your first one.
Created attachment 351921 [details] [review] search-engine-tracker: don't use fts:match on empty search entry If the search entry is empty and filtering for date or mime type is added, then the sparql query always returns nothing because of fts:match '""*' To get the expected search results don't use fts:match when the search text is empty.
Review of attachment 351921 [details] [review]: Looks perfect now, thanks!
Attachment 351921 [details] pushed as fd05b6f - search-engine-tracker: don't use fts:match on empty search entry