summaryrefslogtreecommitdiffstats
path: root/common/changereplay.cpp
Commit message (Collapse)AuthorAge
* Ported to the kasync revampChristian Mollekopf2016-09-15
|
* Don't create a transaction for every revision that we don't replay.Christian Mollekopf2016-09-15
| | | | | This had a significant performance impact when i.e. syncing a folder with 10k messages.
* Don't nest calls too deep.Christian Mollekopf2016-09-15
| | | | The old implementation would result in endlessly nested calls.
* Only change the status once per batch, instead of every revision.Christian Mollekopf2016-07-08
|
* A new debug system.Christian Mollekopf2016-07-07
| | | | | | | | | | | | | | | Instead of a single #define as debug area the new system allows for an identifier for each debug message with the structure component.area. The component is a dot separated identifier of the runtime component, such as the process or the plugin. The area is the code component, and can be as such defined at compiletime. The idea of this system is that it becomes possible to i.e. look at the output of all messages in the query subsystem of a specific resource (something that happens in the client process, but in the resource-specific subcomponent). The new macros are supposed to be less likely to clash with other names, hence the new names.
* Prepare for making the resource status availableChristian Mollekopf2016-07-05
|
* Catch errorsChristian Mollekopf2016-06-21
|
* If the changereplay failed we have to stop.Christian Mollekopf2016-06-17
| | | | | Otherwise we would never replay changes that failed because we were offline or so.
* Fixed issues found by clang analyzerChristian Mollekopf2016-06-14
|
* Deal with errors in the change-replay job.Christian Mollekopf2016-06-03
|
* Non blocking change-replayChristian Mollekopf2016-06-02
|
* Fixed genericresource so it works with the maildirresourcetestChristian Mollekopf2016-05-29
|
* Refactored the generic resource to use separate classes forChristian Mollekopf2016-05-28
changereplay and synchronization. This cleans up the API and avoids the excessive passing around of transactions. It also provides more flexibility in eventually using different synchronization strategies for different resources.