GNOME Bugzilla – Bug 665158
Split search into words
Last modified: 2011-12-01 19:37:49 UTC
See patches. This is what we do in gnome-shell, and I think it makes sense to adopt in gnome-documents as well. For instance, it is currently only possible to search for either author xor title. With attached patch, author/title are matched against each term, and the results AND'ed.
Created attachment 202404 [details] [review] manager: Add forEachItem helper method Subclasses of BaseManager may want to iterate over the managed items - add a helper method which allows to do this without accessing private properties of the parent.
Created attachment 202405 [details] [review] searchbar: Split search into words Rather than using the search entry text as a single term when building the query, split the text into multiple terms and concatenate the results. That way, a search can be refined by adding more words to a query, which is generally more useful (possibly with the exception of full-text search).
Review of attachment 202404 [details] [review]: Looks good.
Review of attachment 202405 [details] [review]: So, if I understand correctly the behaviour change you're proposing here is: - let's pretend I am searching for title and I have a document called "gnome rocks" - without the patch, searching for the string "gnome gno" would not return the result, as it would match the string verbatim - with the patch the document would be returned, since it still matches both strings If so, I am fine with the change, especially if the Shell does the same; wondering if it impacts the query performance at all to have more filter conditions put in AND that way. ::: src/searchbar.js @@ +216,3 @@ + + getFilter: function() { + let terms = Global.searchController.getString().replace(/ +/g, ' ').split(' '); Can you make this a method on SearchController? (e.g. getTerms()) I believe it's clearer.
Created attachment 202542 [details] [review] searchbar: Split search into words (In reply to comment #4) > Review of attachment 202405 [details] [review]: > > So, if I understand correctly the behaviour change you're proposing here is: > - let's pretend I am searching for title and I have a document called "gnome > rocks" > - without the patch, searching for the string "gnome gno" would not return the > result, as it would match the string verbatim > - with the patch the document would be returned, since it still matches both > strings Yes. Also, "tale dickens" currently does not match a document with author=="charles dickens" and title="a tale of two cities", while it does with the patch. > If so, I am fine with the change, especially if the Shell does the same; > wondering if it impacts the query performance at all to have more filter > conditions put in AND that way. I honestly don't know. We still use a single tracker query, so hopefully the performance impact (if any) is negligible. > ::: src/searchbar.js > Can you make this a method on SearchController? (e.g. getTerms()) > I believe it's clearer. Sure.
Review of attachment 202542 [details] [review]: Thanks, looks good.
Attachment 202404 [details] pushed as a0206d2 - manager: Add forEachItem helper method Attachment 202542 [details] pushed as d2456cd - searchbar: Split search into words