1. 25 Mar, 2020 1 commit
  2. 24 Mar, 2020 1 commit
  3. 23 Mar, 2020 1 commit
  4. 04 Jan, 2020 1 commit
  5. 02 Jan, 2020 1 commit
  6. 05 Oct, 2019 1 commit
    • Daniel Vrátil's avatar
      AkRanges: various cleanups · 1af267e7
      Daniel Vrátil authored
      * Move from Akonadi to AkRanges namespace
      * Introduce Views and Actions namespaces
      * Better names for template parameters
      1af267e7
  7. 13 May, 2019 1 commit
  8. 10 May, 2019 2 commits
  9. 05 Dec, 2018 1 commit
  10. 01 Dec, 2018 1 commit
    • Daniel Vrátil's avatar
      Call QSqlQuery::finish() on all SELECT queries when done · 089ee695
      Daniel Vrátil authored
      It's what documentation says should be done, and once Qt is fixed it
      will also cause the QSqlQuery to free the underlying DBMS' results,
      so that keeping the query around in the caches won't cause them to
      use insane amount of memory, if the last query happened to return a
      lot of results.
      089ee695
  11. 19 Jan, 2018 1 commit
    • Daniel Vrátil's avatar
      Use QIODevice::readyRead() to wait for incoming data · 2058ae6c
      Daniel Vrátil authored
      Also avoid any reading code to be executed in a slot connected to
      readyRead() signal because Qt will not emit readyRead() signal
      recursively. This change is needed to make Akonadi work on Windows,
      because the blocking QLocalSocket::waitForReadyRead() does not work
      reliably there.
      
      On Linux QLocalSocket::waitForReadyRead() is used internally only
      in DataStream for performance reasons. On Windows DataStream will
      internally instantiate a QEventLoop and wait for the readyRead()
      signal, which is more expensive, especially since DataStream can
      get into the wait state multiple times while reading a single
      command.
      2058ae6c
  12. 11 Jan, 2018 1 commit
  13. 09 May, 2017 1 commit
  14. 18 Apr, 2017 1 commit
  15. 05 Apr, 2017 1 commit
  16. 01 Apr, 2017 1 commit
  17. 24 Feb, 2017 1 commit
    • Daniel Vrátil's avatar
      Fix crash when Connection is closed while ItemRetriever is running · 1593c17d
      Daniel Vrátil authored
      ItemRetriever::exec() runs a nested QEventLoop. If the parent
      Connection is terminated while the event loop is running, the
      delayed AkThread::quit() invocation is executed and the thread
      is destroyed, while technically there is still execution going
      on. To workaround that issue we don't destroy the thread in
      Connection::quit() if we detect a nested QEventLoop but instead
      we just notify the event loop to quit and destroy the thread
      later when execution returns back to ItemRetriever::slotNewData().
      
      This fixes a crash in QPSQLQuery, which was dereferencing a
      QPSQLDriver after the driver has been deleted as the thread was
      destroyed and avoids more of random crashes due to the Connection
      being virtually deleted from its own nested event loop.
      
      BUG: 374734
      FIXED-IN: 5.4.3
      1593c17d
  18. 16 Feb, 2017 2 commits
    • David Faure's avatar
      Fix ItemRetriever in case of concurrent requests for the same item(s) · d42f9470
      David Faure authored
      Summary:
      - ItemRetrievalManager must emit requestFinished() for those other requests,
      otherwise the list of pending requests in ItemRetriever is never emptied
      
      - ItemRetriever must not assume that a signal being emitted by
      ItemRetrievalManager is necessarily about the request it's waiting for, it
      could be for another one. So it must first check in its list of pending
      requests to determine whether it should react or not.
      
      With multithreaded unittest, checked for races with clang+tsan.
      (There is one race, the connect to ItemRetrievalRequest vs the emit
      in other threads, we should lock mLock before connect...)
      
      Test Plan: new unittest
      
      Reviewers: dvratil
      
      Reviewed By: dvratil
      
      Subscribers: #kde_pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D4618
      d42f9470
    • Laurent Montel's avatar
      GIT_SILENT: increase version · 550c33fe
      Laurent Montel authored
      550c33fe
  19. 13 Jan, 2017 1 commit
  20. 06 Jan, 2017 1 commit
  21. 02 Jan, 2017 1 commit
  22. 25 Dec, 2016 1 commit
    • Daniel Vrátil's avatar
      Make ItemRetriever cancelable · 1b29a28a
      Daniel Vrátil authored
      Currently we only make use of it only when client disconnects while
      the ItemRetriever is in progress. Currently the client also disconnects
      when it wants to kill a job prematurely.
      1b29a28a
  23. 21 Dec, 2016 1 commit
  24. 13 Oct, 2016 1 commit
  25. 15 Aug, 2016 1 commit
    • Daniel Vrátil's avatar
      Fix a loop in ItemRetriever and make it interactive, add a unit test · 39bcc7d5
      Daniel Vrátil authored
      Fix a loop in ItemRetriever when we have more parts available
      than requested as well as when only some requested parts need
      to be retrieved.
      
      Make ItemRetriever interactive by emitting a signal with list
      of already retrieved items and using QEventLoop to block inside
      ItemRetriever::exec() instead of blocking on a QWaitCondition
      inside ItemRetrievalManager.
      
      Add a unit-test with several different scenarios.
      39bcc7d5
  26. 13 Aug, 2016 2 commits
  27. 10 Aug, 2016 2 commits
    • Daniel Vrátil's avatar
      ItemRetriever: group retrieval requests by Collection · 766c1813
      Daniel Vrátil authored
      ... instead of Resource. Requesting multiple Items from single
      Collections in one batch makes it easier for Resources to process
      the request. Since each Collection belongs to exactly one Resource,
      the Resource groupping is preserved as well.
      766c1813
    • Daniel Vrátil's avatar
      Introduce batch Resource Item retrieval (ABI break) · 81652601
      Daniel Vrátil authored
      One of the bottlenecks in the current design is the individual Item
      retrieval via requestItemDelivery(). The Server does a request for
      the first Item, then waits for the Resource to deliver before requesting
      the next Item and so on. This patch changes the signature of the
      requestItemDelivery() DBus method to support passing multiple Items
      (Item IDs to be specific) at once. The patch also deprecates
      ResourceBase::retrieveItem() in favor of a newly introduces
      ResourceBase::retrieveItems() overload (which takes Item::List and
      set of part names as arguments) allowing resource implementations to
      process all the requested Items in a single batch and pass them back
      to the Server. This should be much faster than querying the Items one
      by one.
      
      This change does not remove the retrieveItem() method, but only
      deprecates it. When Resource only implements retrieveItem() and not
      the new retrieveItems() then retrieveItems() will split the ResourceScheduler
      Task into many single-Item Tasks and will call retrieveItem() for
      each of them.
      
      The next step is to get rid of DBus in here and use a dedicated
      command bus where the Server could request the Items via the Protocol
      and would be handed the Items back through the bus.
      
      Once all resources are ported to the new API, the old retrieveItem()
      method should be removed.
      81652601
  28. 23 Apr, 2016 1 commit
  29. 07 Nov, 2015 1 commit
  30. 28 Aug, 2015 2 commits
    • Daniel Vrátil's avatar
      Slightly speed up ItemRetriever main query (remove two JOINs) · 3bece354
      Daniel Vrátil authored
      Don't join MimeTypeTable and ResourceTable, instead use the same trick as with
      mimetype and flags in FetchHelper, that is local name cache and T::retrieveById().
      This is not much, but on large folders it should slightly reduce the query
      execution time. The major bottleneck here is still the sorting, but we cannot
      really get rid of it.
      
      See T628 on Phabricator for more details and measurements.
      3bece354
    • Daniel Vrátil's avatar
      Add sorting indexes for PimItemTable and friends · ae787c64
      Daniel Vrátil authored
      FetchHelper always retrieves data from DB as "ORDER BY PimItemTable.id DESC",
      which is costly, because PKs are always assumed to be ascending, thus DB has
      to costly calculate the sorting. This patch creates new DESC index on relevant
      columns to speed up the sorting. In some cases this reduces query runtime by
      50% (measured on PSQL).
      
      Note that while all 3 backends support the syntax, only PostgreSQL and partially
      SQLite actually make use of the DESC sorting index. MySQL just ignores the
      keywords. SQLite support depends on version and database file format.
      
      See T628 on Phabricator for more details and measurements.
      ae787c64
  31. 06 Aug, 2015 1 commit
    • Daniel Vrátil's avatar
      ItemRetriever: remove duplicate part names · 8c72a641
      Daniel Vrátil authored
      Originally the code was using QSet, which took care of it for us,
      but using QVector is more efficient in this case, so we need to
      make sure that the vector of part names we get does not contain
      duplicates, otherwise the code in exec() asserts.
      
      The code should be quite effective, since the vector usually
      contains only one or two part types.
      
      Discovered by itemfetchtest in kdepimlibs.
      8c72a641
  32. 27 Jul, 2015 1 commit
  33. 25 Jul, 2015 1 commit
  34. 29 Jun, 2015 1 commit
  35. 26 Jun, 2015 1 commit