1. 20 Jun, 2017 1 commit
  2. 23 Jan, 2017 1 commit
  3. 02 Sep, 2016 1 commit
  4. 29 Jun, 2016 1 commit
  5. 29 Nov, 2015 1 commit
  6. 14 Aug, 2015 1 commit
  7. 27 Jul, 2015 1 commit
  8. 06 Dec, 2014 1 commit
  9. 07 Nov, 2014 1 commit
  10. 16 May, 2014 1 commit
  11. 11 Apr, 2014 1 commit
  12. 10 Apr, 2014 1 commit
  13. 08 Apr, 2014 1 commit
  14. 03 Feb, 2014 1 commit
    • Daniel Vrátil's avatar
      Implement support for server-side search in Akonadi · 8e6cf2de
      Daniel Vrátil authored
      Instead of using Nepomuk and SPARQL queries, we now use SearchQuery and SearchTerm objects
      to construct queries (internally represented as a JSON query language based on Baloo's
      query language.
      
      We now also support server-search, so agents that implement AgentSearchInterface can search
      their storage service (like IMAP SEARCH for example) and return results back to Akonadi. This
      allows us to search even items that are not indexed by a local indexing service, like Nepomuk
      or Baloo.
      
      Big thanks to Christian Mollekopf for his help
      
      Squashed commit from akonadi/server-search branch.
      8e6cf2de
  15. 23 Dec, 2013 1 commit
  16. 19 Nov, 2013 1 commit
  17. 06 Mar, 2013 1 commit
  18. 23 Jan, 2013 1 commit
    • Till Adam's avatar
      Use a faster contains expression for "start of word" matches. · 410bdb1f
      Till Adam authored
      For the special case of address completion, we are really only
      interested in matching at the start of various parts of the name, first
      name, email, etc. So for that case, use bif:contains('foo*') rather than
      the much more expensive regexp match. Speeds up addressee completion
      something fierce for a minor loss in functionality, namely arbitrary
      substring matching.
      (cherry picked from commit c37f8d7023c3e486762af0379e36708d7eb99cea)
      410bdb1f
  19. 22 Jan, 2013 1 commit
    • Till Adam's avatar
      Use a faster contains expression for "start of word" matches. · 14b4f3b6
      Till Adam authored
      For the special case of address completion, we are really only
      interested in matching at the start of various parts of the name, first
      name, email, etc. So for that case, use bif:contains('foo*') rather than
      the much more expensive regexp match. Speeds up addressee completion
      something fierce for a minor loss in functionality, namely arbitrary
      substring matching.
      14b4f3b6
  20. 10 Jan, 2013 1 commit
  21. 01 Nov, 2012 1 commit
    • Vishesh Handa's avatar
      Optimize Contact Search Job Queries · b1744a3b
      Vishesh Handa authored
      Some of the contact search job queries are pathological, and would
      result in virtuoso consuming a lot of cpu for large amounts of time.
      I've optimized the queries by doing the following -
      
      * Not adding a "?r a nco:Contact" term. This is unnecessary as it
        results in an extra property being matched. Considering that Nepomuk
        data almost always follows the ontologies (the exception is legacy
        data), just using properties which have a domain of nco:Contact should
        guarantee the correct results.
      
      * Avoid unions - Virtuoso cannot optimize the unions that well. Instead
        we use a FILTER(?p in (..)) instead.
      
      * Avoding regex based search - Regex based search will always be
        terribly slow. It literally applies the regular expression on each
        candidate in order to filter them out. It's a lot better to use the
        full text index. This is done using 'bif:contains'. We do loose a
        little bit of accuracy, and we cannot match word boundaries. But I
        think have a good user experience trumps a little bit of accuracy.
      
      REVIEW: 107065
      b1744a3b
  22. 25 Oct, 2012 1 commit
  23. 22 Sep, 2012 1 commit
  24. 04 Aug, 2012 1 commit
  25. 21 Mar, 2012 2 commits
    • Laurent Montel's avatar
      Fix compile with no cast ascii · b4c52623
      Laurent Montel authored
      b4c52623
    • Till Adam's avatar
      Improve contains queries. · 85b443dd
      Till Adam authored
      If we are searching for 2 characters or less, we assume substring
      matches anywhere don't make much sense, so we use whole word matching
      via the relatively fast bif:contains. If we are looking for longer
      substrings, we can search for the substring anywhere, using a regex
      filter, or for the substring at the start of words, using a faster regex
      that limits to word boundaries. The later is useful in particul for
      address completion, which is a frequent enough special case to warrant
      optimizing it a bit.
      
      REVIEW: 104338
      85b443dd
  26. 11 Mar, 2012 2 commits
  27. 27 Oct, 2010 1 commit
  28. 03 Aug, 2010 1 commit
  29. 18 Jun, 2010 1 commit
  30. 21 May, 2010 1 commit
  31. 20 Mar, 2010 1 commit
  32. 24 Feb, 2010 2 commits
  33. 22 Feb, 2010 1 commit
    • Thomas McGuire's avatar
      Improve search performance for searches that don't have a LIMIT set. · 81a158df
      Thomas McGuire authored
      - Only search in PersonContacts. The strigi file indexer creates ordinary Contact object, we
        don't want to search them.
      - use DISTINCT
      - use "graph ?g"
      
      Thanks to Yury G. Kudryashov for his help on IRC.
      
      The search speed was improved from 220 seconds to 20 milliseconds (!) here, when searching for
      my own mail address.
      
      CCBUG: 219687
      
      svn path=/trunk/KDE/kdepimlibs/; revision=1094466
      81a158df
  34. 29 Jan, 2010 2 commits
  35. 11 Jan, 2010 2 commits