maryjane
/
syncevolution
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
syncevolution/src/syncevo/SyncSource.h

3092 lines
118 KiB
C
Raw Normal View History

redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/*
* Copyright (C) 2005-2009 Patrick Ohly <patrick.ohly@gmx.de>
* Copyright (C) 2009 Intel Corporation
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) version 3.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301 USA
*/
#ifndef INCL_SYNCSOURCE
#define INCL_SYNCSOURCE
files and classes renamed, include statements cleaned up The intention is to get rid of the historic and inconsistent naming of some classes and their corresponding files: * EvolutionSyncClient = class derived from Funambol's SyncClient, * SyncEvolutionConfig = SyncEvolution's config With the strict 'namespace SyncEvo' and the syncevo/ path prefix for most header files it is no longer necessary to have "SyncEvolution" or "Evolution" in the names. This patch thus renames as follows: EvolutionSyncClient => SyncContext EvolutionSmartPtr => SmartPtr SyncEvolutionCmdline => Cmdline SyncEvolutionConfig => SyncConfig SyncEvolutionUtil => util The former EvolutionSyncClient always had a role that went beyond just running a sync, for example it also provided config access. With the upcoming server support it also won't be just a client. Thus the new name "SyncContext". The 'syncevo/' prefix is used throughout the code now. removed whenever the prefix made it clear that the file belongs to SyncEvolution. This helps finding incorrect include paths. Quotes should be used exclusively for SyncEvolution files which don't have a specific prefix yet (test.h, config.h) to help identifying them.
2009-10-05 14:49:32 +02:00
#include <syncevo/SyncConfig.h>
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
#include <syncevo/SyncML.h>
core, WebDAV: improved support for aborting while sleeping When waiting for resending a failed message, the sleeping couldn't be interrupted when using the D-Bus server. It now uses the SuspendFlags infrastructure and glib, which detects abort requests sent via D-Bus in addition to those sent via signals (which already worked earlier).
2012-06-20 12:26:12 +02:00
#include <syncevo/Timespec.h>
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
#include <synthesis/sync_declarations.h>
#include <synthesis/syerror.h>
enable suspend and saving blobs (MB #2425) Implement blob support. Blobs are stored in the per-peer source directory in a ".cache" sub-directory. We could have relied on the peer name and device name to make file names unique when sharing a common directory. Perhaps that is indeed the better solution: ~/.cache/syncevolution/blobs with logdir specifying the root? Blob support is only needed when running as server. When running as client, the binfile layer provides the necessary implementation. Support for suspend was off by default because <resumesupport> was not set. Adding it, because we should have whatever is needed. <resumeitemsupport> depends on the ability to store blobs. Not sure whether this is relevant on the client side, where these services are provided by the binfile layer.
2010-03-04 17:50:01 +01:00
#include <synthesis/blobs.h>
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
#include <boost/function.hpp>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
#include <boost/signals2.hpp>
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
#include <boost/variant.hpp>
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
files and classes renamed, include statements cleaned up The intention is to get rid of the historic and inconsistent naming of some classes and their corresponding files: * EvolutionSyncClient = class derived from Funambol's SyncClient, * SyncEvolutionConfig = SyncEvolution's config With the strict 'namespace SyncEvo' and the syncevo/ path prefix for most header files it is no longer necessary to have "SyncEvolution" or "Evolution" in the names. This patch thus renames as follows: EvolutionSyncClient => SyncContext EvolutionSmartPtr => SmartPtr SyncEvolutionCmdline => Cmdline SyncEvolutionConfig => SyncConfig SyncEvolutionUtil => util The former EvolutionSyncClient always had a role that went beyond just running a sync, for example it also provided config access. With the upcoming server support it also won't be just a client. Thus the new name "SyncContext". The 'syncevo/' prefix is used throughout the code now. removed whenever the prefix made it clear that the file belongs to SyncEvolution. This helps finding incorrect include paths. Quotes should be used exclusively for SyncEvolution files which don't have a specific prefix yet (test.h, config.h) to help identifying them.
2009-10-05 14:49:32 +02:00
#include <syncevo/declarations.h>
introduced "namespace SyncEvo" consistently Added syncevo/declarations.h, which has This is now used for all SyncEvolution source files, except for the GTK UI, which is written in plain C. In the library it helps to avoid name clashes. The reason for using defines instead of spelling out "namespace SyncEvo" is twofold: 1. if that should ever become necessary, it is easier to rename the namespace via configure options by changing the define 2. editors don't indent the whole file content
2009-10-02 17:23:53 +02:00
SE_BEGIN_CXX
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
class SyncSource;
compiler: fix warnings/errors reported by clang 2.8 clang 2.8 compiles SyncEvolution + Synthesis faster than g++ 4.4.5 (3:40min instead of 4:10min on my laptop) and produces more useful error reports. This patch fixes the code so that it compiles cleanly with clang when using "-Wall -Werror -Wno-unknown-pragmas". Note that clang 2.6 (Debian Squeeze) goes into an infinite recursion compiling code using gdbus-cxx-bridge.h and dies eventually with a stack overflow - can't be used. Changes necessary for clang: - eptr pointer referencing ambiguous, use *x.get() instead - boost::intrusive_ptr* must be defined before code using it - two-phase template checking requires explicitly specifying members in base classes - name clashes with plain C structs (DBusServer, DBusWatch) are an error and need to be avoided (done with namespaces GDBusCXX and SyncEvo) - floats cannot be inline constants - unused methods in local classes are warned about (left() in SyncML.cpp)
2011-02-18 09:22:36 +01:00
struct SDKInterface;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* This set of parameters always has to be passed when constructing
* SyncSource instances.
*/
struct SyncSourceParams {
/**
* @param name the name needed by SyncSource
* @param nodes a set of config nodes to be used by this source
SyncSourceParams: introduced context information Backends like XMLRPC need information about URL, proxy and SSL settings, etc. This can be done via source specific properties, like evolutionsource, but this is not how this is normally done. It would be nicer if the exising per-peer properties could be used. The goal is that a normal peer configuration can be created from a template with the necessary information to enable sources using that information. This patch makes this possible by adding a context parameter to SyncSourceParams: * @param context Additional non-source config settings. * When running as part of a normal sync, these are the * settings for the peer. When running in a local sync, * these settings come from the "source-config" peer * config inside the config context of the source. * Testing uses "source-config@client-test". On the * command line, this is the config chosen by the * user, which may or may not have peer-specific settings! Note that this still doesn't solve the problem for XMLRPC to SyncML peer sync, because in that case ("normal sync") the context will be the one describing the peer. SyncURL is already used and proxy settings might not match. The XMLRPC backends therefore was not changed and continues to use evolutionsource.
2010-10-08 15:00:08 +02:00
* @param context Additional non-source config settings.
* When running as part of a normal sync, these are the
* settings for the peer. When running in a local sync,
local sync: renamed "source-config" to "target-config" As discussed on the mailing list, "source-config" is ambiguous because the "addressbook/calendar/..." configs are also called "source configs". Now the naming is "sync" config (for the config with syncURL=local://, because it is used for syncing) and "target" config (because it is used as target in a sync config's syncURL). Rejected: "local" config - because the databases are not necessarily local "source" config - see above "client" or "server" config - because both sides might use local data and/or client/server could refer to the role of the peer or the SyncML client/server model used internally
2011-06-29 03:42:43 +02:00
* these settings come from the "target-config" peer
SyncSourceParams: introduced context information Backends like XMLRPC need information about URL, proxy and SSL settings, etc. This can be done via source specific properties, like evolutionsource, but this is not how this is normally done. It would be nicer if the exising per-peer properties could be used. The goal is that a normal peer configuration can be created from a template with the necessary information to enable sources using that information. This patch makes this possible by adding a context parameter to SyncSourceParams: * @param context Additional non-source config settings. * When running as part of a normal sync, these are the * settings for the peer. When running in a local sync, * these settings come from the "source-config" peer * config inside the config context of the source. * Testing uses "source-config@client-test". On the * command line, this is the config chosen by the * user, which may or may not have peer-specific settings! Note that this still doesn't solve the problem for XMLRPC to SyncML peer sync, because in that case ("normal sync") the context will be the one describing the peer. SyncURL is already used and proxy settings might not match. The XMLRPC backends therefore was not changed and continues to use evolutionsource.
2010-10-08 15:00:08 +02:00
* config inside the config context of the source.
local sync: renamed "source-config" to "target-config" As discussed on the mailing list, "source-config" is ambiguous because the "addressbook/calendar/..." configs are also called "source configs". Now the naming is "sync" config (for the config with syncURL=local://, because it is used for syncing) and "target" config (because it is used as target in a sync config's syncURL). Rejected: "local" config - because the databases are not necessarily local "source" config - see above "client" or "server" config - because both sides might use local data and/or client/server could refer to the role of the peer or the SyncML client/server model used internally
2011-06-29 03:42:43 +02:00
* Testing uses "target-config@client-test". On the
SyncSourceParams: introduced context information Backends like XMLRPC need information about URL, proxy and SSL settings, etc. This can be done via source specific properties, like evolutionsource, but this is not how this is normally done. It would be nicer if the exising per-peer properties could be used. The goal is that a normal peer configuration can be created from a template with the necessary information to enable sources using that information. This patch makes this possible by adding a context parameter to SyncSourceParams: * @param context Additional non-source config settings. * When running as part of a normal sync, these are the * settings for the peer. When running in a local sync, * these settings come from the "source-config" peer * config inside the config context of the source. * Testing uses "source-config@client-test". On the * command line, this is the config chosen by the * user, which may or may not have peer-specific settings! Note that this still doesn't solve the problem for XMLRPC to SyncML peer sync, because in that case ("normal sync") the context will be the one describing the peer. SyncURL is already used and proxy settings might not match. The XMLRPC backends therefore was not changed and continues to use evolutionsource.
2010-10-08 15:00:08 +02:00
* command line, this is the config chosen by the
* user, which may or may not have peer-specific settings!
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
* @param contextName optional name of context in which the source is defined,
* needed to disambiguates "name" when sources from
* different contexts are active in a sync
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
SyncSourceParams(const string &name,
SyncSourceParams: introduced context information Backends like XMLRPC need information about URL, proxy and SSL settings, etc. This can be done via source specific properties, like evolutionsource, but this is not how this is normally done. It would be nicer if the exising per-peer properties could be used. The goal is that a normal peer configuration can be created from a template with the necessary information to enable sources using that information. This patch makes this possible by adding a context parameter to SyncSourceParams: * @param context Additional non-source config settings. * When running as part of a normal sync, these are the * settings for the peer. When running in a local sync, * these settings come from the "source-config" peer * config inside the config context of the source. * Testing uses "source-config@client-test". On the * command line, this is the config chosen by the * user, which may or may not have peer-specific settings! Note that this still doesn't solve the problem for XMLRPC to SyncML peer sync, because in that case ("normal sync") the context will be the one describing the peer. SyncURL is already used and proxy settings might not match. The XMLRPC backends therefore was not changed and continues to use evolutionsource.
2010-10-08 15:00:08 +02:00
const SyncSourceNodes &nodes,
SyncSource config: grant sources read/write access to context The intention always was that backends may add their own properties. For sync properties this seemed less relevant, so sources only got read access to it. But the WebDAV backends run with their own "source-config" context and now need read/write access to store information that is shared between all sources. Therefore this patch removes the "const" qualifier from SyncConfig.
2011-04-15 13:26:55 +02:00
const boost::shared_ptr<SyncConfig> &context,
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
const string &contextName = "") :
config: reorganized for shared config layout (MB#7707) This patch introduces code changes for the new layout without actually using it yet. Therefore all existing tests for the older layout still pass. The new meaning of the former "server name" is introduced: - A plain string now refers to a peer configuration (can be client or server). - The @ sign allows selecting a specific context. Different contexts have independent sets of local sources and peer definitions. - An empty peer name selects a view on the configuration which contains no peer-specific properties. Not fully implemented yet. The FileConfigTree is instantiated with a root which is one level high up compare to before this patch (for example, "~/.config/syncevolution" instead of "./config/syncevolution/scheduleworld") and then config files include that dropped level in their relative path name ("scheduleworld/config.ini" instead of "config.ini"). This allows accessing the global properties in "~/.config/syncevolution/config.ini" and will be used to move peers further down the hierarchy ("~/.config/syncevolution/peers/scheduleworld/config.ini"). To keep the output of "--print-servers" consistent, the FileConfigTree gets another parameter which identifies the subset of the larger tree that is referenced by this FileConfigTree instance. One side effect of this change is that FileConfigTree instances are no longer completely separate. Something to keep in mind when instantiating SyncContext multiple times (MB#8006). Code may no longer make assumptions in which config node a property is stored. This is determined by the new getNode() calls based on the property attributes (hidden, sharing). The new layout is represented as a set of config nodes. Older layouts use the same set of nodes with identical instances assigned to them, if they don't really have separate files for each of them. SyncSourceNodes no longer grants direct access to the nodes, to catch code which incorrectly access a specific node directly. For the same reason the name of the nodes changed. Code which needs access to all hidden or all visible properties now does this via a config node returned by getProperties(). Currently this is identical to the underlying nodes. Once the new layout is active, this node will act as a multiplexer which gathers properties from all underlying nodes when reading and picks the right one when writing. The "change ID" parameter for sources has been obsolete for a while and was removed. Reorganized the property registration so that it is a bit easier to see which properties are hidden and which use non-default sharing. The default sharing is "no sharing". Some other code was improved while touching it: - removed useless visibility[] array in favor of a i != 0 check in SyncConfig::copy() - added default parameters to save/checkPassword() methods - some constness definition changes - Property::getProperty() is a virtual call which could only be overloaded in one case because the constness was wrong; now getProperty() always returns the string value and getPropertyValue() some other kind of representation of it, depending on the class. - ConstSyncSourceNodes is based on SyncSourceNodes instead of duplicating it, which simplifies the implementation. The simplified SyncSourceAdmin API changed slightly: instead of passing a pointer to the source's SyncSourceNodes, the default nodes are now found via the SyncSource pointer. For callers this is a bit less work and it is more general.
2009-11-13 14:52:00 +01:00
m_name(name),
SyncSourceParams: introduced context information Backends like XMLRPC need information about URL, proxy and SSL settings, etc. This can be done via source specific properties, like evolutionsource, but this is not how this is normally done. It would be nicer if the exising per-peer properties could be used. The goal is that a normal peer configuration can be created from a template with the necessary information to enable sources using that information. This patch makes this possible by adding a context parameter to SyncSourceParams: * @param context Additional non-source config settings. * When running as part of a normal sync, these are the * settings for the peer. When running in a local sync, * these settings come from the "source-config" peer * config inside the config context of the source. * Testing uses "source-config@client-test". On the * command line, this is the config chosen by the * user, which may or may not have peer-specific settings! Note that this still doesn't solve the problem for XMLRPC to SyncML peer sync, because in that case ("normal sync") the context will be the one describing the peer. SyncURL is already used and proxy settings might not match. The XMLRPC backends therefore was not changed and continues to use evolutionsource.
2010-10-08 15:00:08 +02:00
m_nodes(nodes),
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
m_context(context),
m_contextName(contextName)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
{}
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
std::string getDisplayName() const { return m_contextName.empty() ? m_name : m_contextName + "/" + m_name; }
config: reorganized for shared config layout (MB#7707) This patch introduces code changes for the new layout without actually using it yet. Therefore all existing tests for the older layout still pass. The new meaning of the former "server name" is introduced: - A plain string now refers to a peer configuration (can be client or server). - The @ sign allows selecting a specific context. Different contexts have independent sets of local sources and peer definitions. - An empty peer name selects a view on the configuration which contains no peer-specific properties. Not fully implemented yet. The FileConfigTree is instantiated with a root which is one level high up compare to before this patch (for example, "~/.config/syncevolution" instead of "./config/syncevolution/scheduleworld") and then config files include that dropped level in their relative path name ("scheduleworld/config.ini" instead of "config.ini"). This allows accessing the global properties in "~/.config/syncevolution/config.ini" and will be used to move peers further down the hierarchy ("~/.config/syncevolution/peers/scheduleworld/config.ini"). To keep the output of "--print-servers" consistent, the FileConfigTree gets another parameter which identifies the subset of the larger tree that is referenced by this FileConfigTree instance. One side effect of this change is that FileConfigTree instances are no longer completely separate. Something to keep in mind when instantiating SyncContext multiple times (MB#8006). Code may no longer make assumptions in which config node a property is stored. This is determined by the new getNode() calls based on the property attributes (hidden, sharing). The new layout is represented as a set of config nodes. Older layouts use the same set of nodes with identical instances assigned to them, if they don't really have separate files for each of them. SyncSourceNodes no longer grants direct access to the nodes, to catch code which incorrectly access a specific node directly. For the same reason the name of the nodes changed. Code which needs access to all hidden or all visible properties now does this via a config node returned by getProperties(). Currently this is identical to the underlying nodes. Once the new layout is active, this node will act as a multiplexer which gathers properties from all underlying nodes when reading and picks the right one when writing. The "change ID" parameter for sources has been obsolete for a while and was removed. Reorganized the property registration so that it is a bit easier to see which properties are hidden and which use non-default sharing. The default sharing is "no sharing". Some other code was improved while touching it: - removed useless visibility[] array in favor of a i != 0 check in SyncConfig::copy() - added default parameters to save/checkPassword() methods - some constness definition changes - Property::getProperty() is a virtual call which could only be overloaded in one case because the constness was wrong; now getProperty() always returns the string value and getPropertyValue() some other kind of representation of it, depending on the class. - ConstSyncSourceNodes is based on SyncSourceNodes instead of duplicating it, which simplifies the implementation. The simplified SyncSourceAdmin API changed slightly: instead of passing a pointer to the source's SyncSourceNodes, the default nodes are now found via the SyncSource pointer. For callers this is a bit less work and it is more general.
2009-11-13 14:52:00 +01:00
string m_name;
SyncSourceNodes m_nodes;
SyncSource config: grant sources read/write access to context The intention always was that backends may add their own properties. For sync properties this seemed less relevant, so sources only got read access to it. But the WebDAV backends run with their own "source-config" context and now need read/write access to store information that is shared between all sources. Therefore this patch removes the "const" qualifier from SyncConfig.
2011-04-15 13:26:55 +02:00
boost::shared_ptr<SyncConfig> m_context;
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
string m_contextName;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
/**
* The SyncEvolution core has no knowledge of existing SyncSource
* implementations. Implementations have to register themselves
* by instantiating this class exactly once with information
* about themselves.
*
* It is also possible to add configuration options. For that define a
* derived class. In its constructor use
* SyncSourceConfig::getRegistry() resp. SyncConfig::getRegistry() to
* define new configuration properties. The advantage of registering
* them is that the user interface will automatically handle them like
* the predefined ones. The namespace of these configuration options
* is shared by all sources and the core.
*
* For properties with arbitrary names use the
* SyncSourceNodes::m_trackingNode.
*/
class RegisterSyncSource
{
public:
/**
* Users select a SyncSource and its data format via the "type"
* config property. Backends have to add this kind of function to
* the SourceRegistry_t in order to be considered by the
* SyncSource creation mechanism.
*
* The function will be called to check whether the backend was
* meant by the user. It should return a new instance which will
* be freed by the caller or NULL if it does not support the
* selected type.
*
* Inactive sources should return the special InactiveSource
SyncSource: remove special RegisterSyncSource::InactiveSource pointer The special semantic of the former RegisterSyncSource::InactiveSource (invalid pointer of value 1) caused bugs, like using it in --print-databases (=> segfault) or not being able to store the result of a createSource() directly in a smart pointer (=> potential leak in SyncSource::createSource()). Obviously a bad idea to start with. Replaced with a RegisterSyncSource::InactiveSource() method which creates a real, inactive SyncSource instance which can and must be deleted by the caller. This is a SyncSource API change for backend developers. Instead of RegisterSyncSource::InactiveSource, return RegisterSyncSource::InactiveSource(). Comparisons against RegisterSyncSource::InactiveSource needs to be replaced with a call to the new SyncSource::isInactive(). User visible fixes: * --print-databases: no longer crashes when EDS or KDE backends are not usable. Instead it prints "not enabled during compilation or not usable in the current environment". * --print-databases: continues with other backends even if one backend throws an exception, as the KDE backend does when it cannot find Akonadi. Error messages are printed.
2012-03-08 11:15:22 +01:00
* instance (created with InactiveSource() below) if they
* recognize without a doubt that the user wanted to instantiate
* them: for example, an inactive EvolutionContactSource will
* return NULL for "addressbook" but InactiveSource for
* "evolution-contacts".
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
typedef SyncSource *(*Create_t)(const SyncSourceParams &params);
SyncSource: remove special RegisterSyncSource::InactiveSource pointer The special semantic of the former RegisterSyncSource::InactiveSource (invalid pointer of value 1) caused bugs, like using it in --print-databases (=> segfault) or not being able to store the result of a createSource() directly in a smart pointer (=> potential leak in SyncSource::createSource()). Obviously a bad idea to start with. Replaced with a RegisterSyncSource::InactiveSource() method which creates a real, inactive SyncSource instance which can and must be deleted by the caller. This is a SyncSource API change for backend developers. Instead of RegisterSyncSource::InactiveSource, return RegisterSyncSource::InactiveSource(). Comparisons against RegisterSyncSource::InactiveSource needs to be replaced with a call to the new SyncSource::isInactive(). User visible fixes: * --print-databases: no longer crashes when EDS or KDE backends are not usable. Instead it prints "not enabled during compilation or not usable in the current environment". * --print-databases: continues with other backends even if one backend throws an exception, as the KDE backend does when it cannot find Akonadi. Error messages are printed.
2012-03-08 11:15:22 +01:00
/** create special result of Create_t: a source which just throws errors when used */
static SyncSource *InactiveSource(const SyncSourceParams &params);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* @param shortDescr a few words identifying the data to be synchronized,
* e.g. "Evolution Calendar"
* @param enabled true if the sync source can be instantiated,
* false if it was not enabled during compilation or is
* otherwise not functional
* @param create factory function for sync sources of this type
* @param typeDescr multiple lines separated by \n which get appended to
* the the description of the type property, e.g.
* "Evolution Memos = memo = evolution-memo\n"
* " plain text in UTF-8 (default) = text/plain\n"
* " iCalendar 2.0 = text/calendar\n"
* " The later format is not tested because none of the\n"
* " supported SyncML servers accepts it.\n"
* @param typeValues the config accepts multiple names for the same internal
* type string; this list here is added to that list of
* aliases. It should contain at least one unique string
* the can be used to pick this sync source among all
* SyncEvolution sync sources (testing, listing backends, ...).
* Example: Values() + (Aliases("Evolution Memos") + "evolution-memo")
*/
RegisterSyncSource(const string &shortDescr,
bool enabled,
Create_t create,
const string &typeDescr,
const Values &typeValues);
public:
const string m_shortDescr;
const bool m_enabled;
const Create_t m_create;
const string m_typeDescr;
const Values m_typeValues;
};
typedef list<const RegisterSyncSource *> SourceRegistry;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
class ClientTest;
class TestingSyncSource;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
* Information about a data source. For the sake of simplicity all
* items pointed to are owned by the ClientTest and must
* remain valid throughout a test session. Not setting a pointer
* is okay, but it will disable all tests that need the
* information.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
testing: improved linkedItems tests (with and without VALARM) With Google Calendar, having a VALARM leads to different communication compared to the case without VALARM (requires resending). Test both cases by providing multiple sets of linked items. Client::Source now contains LinkedItems_1 and LinkedItems_2 sub-groups. This required changes in resultchecker.py, to keep these tests as listed in the same table as the other source tests. ClientTestConfig becomes more complicated: it used to be a plain C struct which could be copied/cleaned with memcpy/memset. This approach is kept by adding a pointer to a std::vectore. A nicer solution would be to turn all "const char *" into std::string and int/bool values with wrapper classes which initialize them.
2011-08-25 13:04:22 +02:00
struct ClientTestConfig {
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* The name is used in test names and has to be set.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_sourceName;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A default URI to be used when creating a client config.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_uri;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A corresponding source name in the default server template,
* this is used to copy corresponding uri set in the server template
* instead of the uri field above (which is the same for all servers).
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_sourceNameServerTemplate;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A member function of a subclass which is called to create a
* sync source referencing the data. This is used in tests of
* the SyncSource API itself as well as in tests which need to
* modify or check the data sources used during synchronization.
*
* The test framework will call beginSync() and then some of
* the functions it wants to test. After a successful test it
* will call endSync() which is then expected to store all
* changes persistently. Creating a sync source again
* with the same call should not report any
* new/updated/deleted items until such changes are made via
* another sync source.
*
* The instance will be deleted by the caller. Because this
* may be in the error case or in an exception handler,
* the sync source's desctructor should not thow exceptions.
*
* @param client the same instance to which this config belongs
testing: enhanced DAV source testing + infrastructure The main goal is to test CalDAV/CardDAV sources as part of a SyncML client and/or server. A test involving syncevo-http-server is now named "<client storage><server storage>": - edsfile = EDS in client, file in server (used to be syncevohttp) - davfile = CalDAV/CardDAV in client, file in server (new) - edsdav = EDS in client, CalDAV/CardDAV in server (new) For this, WebDAVSourceRegister.cpp must be able to create test sources which match the client 1/2 sync configs. The client "1" or "2" strings are passed through the abstract ClientTest into the source A/B create callbacks. WebDAVSourceRegister.cpp cannot get this directly from ClientTest because it lives in a plugin which is not necessarily linked against ClientTest. A conceptual change is that CLIENT_TEST_EVOLUTION_PREFIX/USER/PASSWORD no longer override existing config properties. That is necessary because the shared prefix is too simplistic for WebDAV (needs full URL in "database"); also helps KDE (needs resource URI). The env variables and the default "SyncEvolution_Test_" value for the database prefix are still used if the config does not exist. That is useful to prevent accidentally running client-test against the default databases. The nightly setup script might (should!?) be made public to simplify configuring a server. Another change is the user-configurable part of client-test now lives entirely in the _1/_2 client sync configs and contexts. From there the source properties are copied into the Client::Source context each time client-test runs.
2012-04-23 13:03:32 +02:00
* @param clientID the unique ID of the client, "1" resp. "2" in practice (can also be obtained as
* client->getClientID(), but not all implementers have (or want) access to the
* class definition)
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
* @param source index of the data source (from 0 to ClientTest::getNumSources() - 1)
* @param isSourceA true if the requested SyncSource is the first one accessing that
* data, otherwise the second
*/
testing: enhanced DAV source testing + infrastructure The main goal is to test CalDAV/CardDAV sources as part of a SyncML client and/or server. A test involving syncevo-http-server is now named "<client storage><server storage>": - edsfile = EDS in client, file in server (used to be syncevohttp) - davfile = CalDAV/CardDAV in client, file in server (new) - edsdav = EDS in client, CalDAV/CardDAV in server (new) For this, WebDAVSourceRegister.cpp must be able to create test sources which match the client 1/2 sync configs. The client "1" or "2" strings are passed through the abstract ClientTest into the source A/B create callbacks. WebDAVSourceRegister.cpp cannot get this directly from ClientTest because it lives in a plugin which is not necessarily linked against ClientTest. A conceptual change is that CLIENT_TEST_EVOLUTION_PREFIX/USER/PASSWORD no longer override existing config properties. That is necessary because the shared prefix is too simplistic for WebDAV (needs full URL in "database"); also helps KDE (needs resource URI). The env variables and the default "SyncEvolution_Test_" value for the database prefix are still used if the config does not exist. That is useful to prevent accidentally running client-test against the default databases. The nightly setup script might (should!?) be made public to simplify configuring a server. Another change is the user-configurable part of client-test now lives entirely in the _1/_2 client sync configs and contexts. From there the source properties are copied into the Client::Source context each time client-test runs.
2012-04-23 13:03:32 +02:00
typedef boost::function<TestingSyncSource *(ClientTest &, const std::string &, int, bool)> createsource_t;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* Creates a sync source which references the primary database;
* it may report the same changes as the sync source used during
* sync tests.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
createsource_t m_createSourceA;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A second sync source also referencing the primary data
* source, but configured so that it tracks changes
* independently from the the primary sync source.
*
* In local tests the usage is like this:
* - add item via first SyncSource
* - iterate over new items in second SyncSource
* - check that it lists the added item
*
* In tests with a server the usage is:
* - do a synchronization with the server
* - iterate over items in second SyncSource
* - check that the total number and number of
* added/updated/deleted items is as expected
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
createsource_t m_createSourceB;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* The framework can generate vCard and vCalendar/iCalendar items
* automatically by copying a template item and modifying certain
* properties.
*
* This is the template for these automatically generated items.
* It must contain the string <<REVISION>> which will be replaced
* with the revision parameter of the createItem() method.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_templateItem;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* This is a colon (:) separated list of properties which need
* to be modified in templateItem.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_uniqueProperties;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* This is a single property in templateItem which can be extended
* to increase the size of generated items.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_sizeProperty;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* Type to be set when importing any of the items into the
* corresponding sync sources. Use "" if sync source doesn't
* need this information.
*
* Not currently used! All items are assumed to be in the raw,
* internal format (see SyncSourceRaw and SyncSourceSerialize).
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_itemType;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
nightly testing: improved handling of test data Previously, test data was modified once when creating the test configuration. That turned out to be too limited for Google Calendar, which requires operations like "bump SEQUENCE number" each time a test case is used. This patch therefore introduces a "mangleItem" callback. In most cases, it doesn't do anything. But for iCalendar 2.0, it applies the transformations previously found in the config setup (simplify UID, ...) and adds some new ones (increase SEQUENCE number, set LAST-MODIFIED to current time, avoid conflicts between different test runs by making the UID unique to the run if CLIENT_TEST_UNIQUE_UID is set). The patch also fixes time stamps in the test data: they should have been in UTC, but lacked the Z suffix.
2010-10-14 11:40:45 +02:00
/**
* callback which is invoked with a specific item as paramter
* to do data type specific conversions before actually
* using the test item; default is a NOP function
testing: avoid race condition in testLinkedItem* tests The testLinkedItem tests updated items without actually modifying their content. That worked as long as LAST-MODIFIED increased, but because of the recent speed-ups that was no longer always the case. The test then failed because the ETag of a CalDAV resource didn't changed on the Apple Calendar Server. This commit fixes that by modifying the item content when it is to be used as an update. One test didn't take that into account and continued using the unmodified item content. Fixed.
2011-06-25 17:20:22 +02:00
*
* @param update modify item content so that it can be
* used as an update of the old data
testing: more workarounds for Google CalDAV + unique IDs Google became even more strict about checking REV. Tests which reused a UID after deleting the original item started to fail sometime since middle of December 2012. To fix this, tests must differentiate reuse of an item by adding a suffix ("-A", "-B", etc.). If CLIENT_TEST_UNIQUE_UID has a value >= 2, that suffix will be used when mangling the input item. Otherwise the suffix is ignored and nothing changes. For testing Google, CLIENT_TEST_UNIQUE_UID=2 is used.
2013-02-21 08:23:01 +01:00
* @param uniqueUIDSuffix beyond not reusing UIDs between tests, also embed this suffix
* in test items inside the running test to avoid reuse
* if necessary (Google CalDAV + UID/SEQUENCE => 409 error)
nightly testing: improved handling of test data Previously, test data was modified once when creating the test configuration. That turned out to be too limited for Google Calendar, which requires operations like "bump SEQUENCE number" each time a test case is used. This patch therefore introduces a "mangleItem" callback. In most cases, it doesn't do anything. But for iCalendar 2.0, it applies the transformations previously found in the config setup (simplify UID, ...) and adds some new ones (increase SEQUENCE number, set LAST-MODIFIED to current time, avoid conflicts between different test runs by making the UID unique to the run if CLIENT_TEST_UNIQUE_UID is set). The patch also fixes time stamps in the test data: they should have been in UTC, but lacked the Z suffix.
2010-10-14 11:40:45 +02:00
*/
testing: more workarounds for Google CalDAV + unique IDs Google became even more strict about checking REV. Tests which reused a UID after deleting the original item started to fail sometime since middle of December 2012. To fix this, tests must differentiate reuse of an item by adding a suffix ("-A", "-B", etc.). If CLIENT_TEST_UNIQUE_UID has a value >= 2, that suffix will be used when mangling the input item. Otherwise the suffix is ignored and nothing changes. For testing Google, CLIENT_TEST_UNIQUE_UID=2 is used.
2013-02-21 08:23:01 +01:00
boost::function<std::string (const std::string &data, bool update, const std::string &uniqueUIDSuffix)> m_mangleItem;
nightly testing: improved handling of test data Previously, test data was modified once when creating the test configuration. That turned out to be too limited for Google Calendar, which requires operations like "bump SEQUENCE number" each time a test case is used. This patch therefore introduces a "mangleItem" callback. In most cases, it doesn't do anything. But for iCalendar 2.0, it applies the transformations previously found in the config setup (simplify UID, ...) and adds some new ones (increase SEQUENCE number, set LAST-MODIFIED to current time, avoid conflicts between different test runs by making the UID unique to the run if CLIENT_TEST_UNIQUE_UID is set). The patch also fixes time stamps in the test data: they should have been in UTC, but lacked the Z suffix.
2010-10-14 11:40:45 +02:00
WebDAV: do not mangle UID when sending items The WebDAV backends contained a hack where the UID inside the data was forced to be identical to the resource name. This is wrong for items created by us via POST (because the server may choose a resource name != UID) or by some other entity (where we have no idea how the resource name got chosen). This commit removes the hack. Testing must be updated to pass correct data with the same UID as on the server when updating an item, because the backend will no longer ensure that and changing the UID of a resource gets rejected by some servers. The hack was introduced for peers which do not store the UID (for example, a vCard or iCalendar 1.0 based SyncML client). A better solution must be found, probably involving the Synthesis engine and its read/update/write cycle.
2014-04-10 15:29:34 +02:00
/**
* Items have a UID which really has to be unique among all items
* in the database. True for iCalendar 2.0, false for vCard 3.0
* (there is a UID, but its uniqueness is not enforced).
*/
bool m_uniqueID;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A very simple item that is inserted during basic tests. Ideally
* it only contains properties supported by all servers.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_insertItem;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A slightly modified version of insertItem. If the source has UIDs
* embedded into the item data, then both must have the same UID.
* Again all servers should better support these modified properties.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_updateItem;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* A more heavily modified version of insertItem. Same UID if necessary,
* but can test changes to items only supported by more advanced
* servers.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_complexUpdateItem;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* To test merge conflicts two different updates of insertItem are
* needed. This is the first such update.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_mergeItem1;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* The second merge update item. To avoid true conflicts it should
* update different properties than mergeItem1, but even then servers
* usually have problems perfectly merging items. Therefore the
* test is run without expecting a certain merge result.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_mergeItem2;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
testing: improved linkedItems tests (with and without VALARM) With Google Calendar, having a VALARM leads to different communication compared to the case without VALARM (requires resending). Test both cases by providing multiple sets of linked items. Client::Source now contains LinkedItems_1 and LinkedItems_2 sub-groups. This required changes in resultchecker.py, to keep these tests as listed in the same table as the other source tests. ClientTestConfig becomes more complicated: it used to be a plain C struct which could be copied/cleaned with memcpy/memset. This approach is kept by adding a pointer to a std::vectore. A nicer solution would be to turn all "const char *" into std::string and int/bool values with wrapper classes which initialize them.
2011-08-25 13:04:22 +02:00
* The items in the inner vector are related: the first one the is
* main one, the other(s) is/are a subordinate ones. The semantic
* is that the main item is complete on it its own, while the
* other normally should only be used in combination with the main
* one.
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
*
* Because SyncML cannot express such dependencies between items,
* a SyncSource has to be able to insert, updated and remove
* both items independently. However, operations which violate
* the semantic of the related items (like deleting the parent, but
* not the child) may have unspecified results (like also deleting
client-test: replaced compile-time LINKED_ITEMS_RELAXED_SEMANTIC with ClientTestConfig::linkedItemsRelaxedSemantic Several different backends share the code of ClientTest.cpp, so compiling it differently based on capablities of a backend does not work once multiple backends are active. Replaced define with config option and enabled the relevant tests only if the backend supports them.
2010-10-26 11:09:17 +02:00
* the child). See linkedItemsRelaxedSemantic and sourceKnowsItemSemantic.
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
*
* One example for main and subordinate items are a recurring
* iCalendar 2.0 event and a detached recurrence.
*/
testing: renamed LinkedItems tests, added "no ID" variants Numbering Client::Source::LinkedItems_xxx with xxx being a number is confusing, in particular when the same number stands for different test data. Now each set of linked items has an additional, unique name which is used for Client::Source::LinkedItems<Name>. Done in combination with adding more linked item tests and slightly reorganizing the logic for adding them: - a default set with VTIMEZONE is added in all cases - some SyncML servers override that default set - others, in particular peers accessed via their own backend, enable additional Client::Source tests on a case-by-case basis Exchange is only tested with its own default set (with "Standard Timezone" as TZID) and the all-day recurring set (as before). All other CalDAV servers are now also tested with the all-day set (previously exclusive to Exchange) and local floating time (= no TZID, new). Google CalDAV can't be tested with local time because it converts such events into the time zone of the current user. All-day events need special test data because Google adds a time to the UNTIL clause (http://code.google.com/p/google-caldav-issues/issues/detail?id=63). synccompare also needs to ignore that Google adds a redundant VTIMEZONE to the all-day test cases. Finally, Client::Source tests for updating a child event (with and without parent) without UID and RECURRENCE-ID inside the payload were added. These properties are removed via text operations. The expectation is that the source is able to add them back (if needed) based on the meta information that it has about the existing item. The file source is unable to do that. When using it in an HTTP server, the server will look to peers like a peer which doesn't support the semantic (which indeed it doesn't) and thus the client will add back the fields.
2011-11-02 12:11:48 +01:00
typedef class LinkedItems : public std::vector<std::string> {
public:
std::string m_name; /**< used as Client::Source::LinkedItems<m_name> */
testing: delay creating expected additional VEVENTs for Exchange They are now created in callbacks instead of doing it in advance for all cases. Improves startup time (creating all of the artificial VEVENTs took considerable time, in particular under valgind) and overall resource consumption (because now only the next events is kept in memory).
2011-12-06 14:34:06 +01:00
StringMap m_options; /**< used to pass additional parameters to the test */
/** for testLinkedItemsSubset: create the additional VEVENT that is added when talking to Exchange;
parameters are start, skip, index and total number of items in that test */
boost::function<std::string (int, int, int, int)> m_testLinkedItemsSubsetAdditional;
testing: renamed LinkedItems tests, added "no ID" variants Numbering Client::Source::LinkedItems_xxx with xxx being a number is confusing, in particular when the same number stands for different test data. Now each set of linked items has an additional, unique name which is used for Client::Source::LinkedItems<Name>. Done in combination with adding more linked item tests and slightly reorganizing the logic for adding them: - a default set with VTIMEZONE is added in all cases - some SyncML servers override that default set - others, in particular peers accessed via their own backend, enable additional Client::Source tests on a case-by-case basis Exchange is only tested with its own default set (with "Standard Timezone" as TZID) and the all-day recurring set (as before). All other CalDAV servers are now also tested with the all-day set (previously exclusive to Exchange) and local floating time (= no TZID, new). Google CalDAV can't be tested with local time because it converts such events into the time zone of the current user. All-day events need special test data because Google adds a time to the UNTIL clause (http://code.google.com/p/google-caldav-issues/issues/detail?id=63). synccompare also needs to ignore that Google adds a redundant VTIMEZONE to the all-day test cases. Finally, Client::Source tests for updating a child event (with and without parent) without UID and RECURRENCE-ID inside the payload were added. These properties are removed via text operations. The expectation is that the source is able to add them back (if needed) based on the meta information that it has about the existing item. The file source is unable to do that. When using it in an HTTP server, the server will look to peers like a peer which doesn't support the semantic (which indeed it doesn't) and thus the client will add back the fields.
2011-11-02 12:11:48 +01:00
} LinkedItems_t;
testing: improved linkedItems tests (with and without VALARM) With Google Calendar, having a VALARM leads to different communication compared to the case without VALARM (requires resending). Test both cases by providing multiple sets of linked items. Client::Source now contains LinkedItems_1 and LinkedItems_2 sub-groups. This required changes in resultchecker.py, to keep these tests as listed in the same table as the other source tests. ClientTestConfig becomes more complicated: it used to be a plain C struct which could be copied/cleaned with memcpy/memset. This approach is kept by adding a pointer to a std::vectore. A nicer solution would be to turn all "const char *" into std::string and int/bool values with wrapper classes which initialize them.
2011-08-25 13:04:22 +02:00
/**
* The linked items may exist in different variations (outer vector).
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
typedef std::vector<LinkedItems_t> MultipleLinkedItems_t;
MultipleLinkedItems_t m_linkedItems;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
testing: added testLinkedItemsSubset for ActiveSync This new test primarily covers the creation of artificial parent events for detached recurrences in the activesyncd (BMC #22831). The activesyncd must be run with EAS_DEBUG_DETACHED_RECURRENCES=1 set, so that the artifical parent event is returned to the client. Otherwise SyncEvolution cannot verify the correct creation of that event. Putting this test into ClientTest.cpp instead of the ActiveSync backend was done because these test cases may also serve as a useful stress test for other backends. At the moment, they are only enabled when CLIENT_TEST_SERVER is "exchange" or "apple". The artificial event is only expected for "exchange". A full test run with all imaginable combination of events would be very slow. Therefore the tests choose roughly five starting points scattered over the year 2012 and limit the number of events for each test to five, except for the initial sequence with no events skipped: that stores all events. The the moment the test is known to fail with Exchange for those weekly events which include the Sundays of the summer/winter time change. The server uses incorrect UTC times in the UNTIL clause. Perhaps the time zone definition that we send to it is not quite correct?
2011-11-17 09:29:08 +01:00
/**
* Another set of linked items for the LinkedItems*::testItemsAll/Second/Third/... tests.
*/
MultipleLinkedItems_t m_linkedItemsSubset;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* Backends atomic modification tests
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
Bool m_atomicModification;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
client-test: replaced compile-time LINKED_ITEMS_RELAXED_SEMANTIC with ClientTestConfig::linkedItemsRelaxedSemantic Several different backends share the code of ClientTest.cpp, so compiling it differently based on capablities of a backend does not work once multiple backends are active. Replaced define with config option and enabled the relevant tests only if the backend supports them.
2010-10-26 11:09:17 +02:00
* set to false to disable tests which slightly violate the
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
* semantic of linked items by inserting children
* before/without their parent
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
Bool m_linkedItemsRelaxedSemantic;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* setting this to false disables tests which depend
* on the source's support for linked item semantic
* (testLinkedItemsInsertParentTwice, testLinkedItemsInsertChildTwice)
testing: fixed testInsertTwice Backends need to declare how they'll react to inserting the same item (= same UID) item twice.
2012-07-10 09:29:34 +02:00
*
* Matches SynthesisInfo::m_globalIDs.
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
Bool m_sourceKnowsItemSemantic;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
testing: introduced ClientTestConfig::sourceLUIDsAreVolatile Necessary for LinkedItem tests when applied to ActiveSync. In that case, items are renumbered as 1:x with x = 1, 2, ... for each clients when a sync anchor is assigned to it, and therefore the LUID comparisons/searches fail although everything is okay. (cherry picked from commit e45e308806524bada86d57353e24714f06edc331)
2011-08-29 13:56:26 +02:00
/**
* Set this to true if the backend does not have IDs which are the
* same for all clients and across slow syncs. For example, when
* testing the ActiveSync backend this field needs to be true,
* because items are renumbered as 1:x with x = 1, 2, ... for each
* clients when a sync anchor is assigned to it.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
Bool m_sourceLUIDsAreVolatile;
testing: introduced ClientTestConfig::sourceLUIDsAreVolatile Necessary for LinkedItem tests when applied to ActiveSync. In that case, items are renumbered as 1:x with x = 1, 2, ... for each clients when a sync anchor is assigned to it, and therefore the LUID comparisons/searches fail although everything is okay. (cherry picked from commit e45e308806524bada86d57353e24714f06edc331)
2011-08-29 13:56:26 +02:00
CalDAV: revised RECURRENCE-ID -> EXDATE support The previous approach (updating the internal cache) had the drawback that X-SYNCEVOLUTION-EXDATE-DETACHED was also sent to the CalDAV server. The work of generating it was done in all cases, even if not needed. Found when running the full test suite. Now the X-SYNCEVOLUTION-EXDATE-DETACHED properties are only added to the icalcomponent that is generated for the engine in readSubItem(). There's still the risk that such an extended VEVENT will be stored again (read/modify/write conflict resolution), so further changes will be needed to filter them out. To ensure that this change doesn't break the intended semantic of X-SYNCEVOLUTION-EXDATE-DETACHED, the presence of these properties is now checked in the LinkedItems::testLinkedItemsParentChild test.
2011-11-12 13:50:09 +01:00
/**
* Set this to true if the backend supports
* X-SYNCEVOLUTION-EXDATE-DETACHED, see CalDAVSource.cpp
* CalDAVSource::readSubItem().
*/
Bool m_supportsReccurenceEXDates;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* called to dump all items into a file, required by tests which need
* to compare items
*
* ClientTest::dump can be used: it will simply dump all items of the source
* with a blank line as separator.
*
* @param source sync source A already created and with beginSync() called
* @param file a file name
* @return error code, 0 for success
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
boost::function<int (ClientTest &, TestingSyncSource &, const std::string &)> m_dump;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* import test items: which these are is determined entirely by
* the implementor, but tests work best if several complex items are
* imported
*
* ClientTest::import can be used if the file contains items separated by
* empty lines.
*
* @param source sync source A already created and with beginSync() called
* @param file the name of the file to import
* @retval realfile the name of the file that was really imported;
* this may depend on the current server that is being tested
testing: added Source::*::testRemoveProperties This is primarily for ActiveSync where the test failed until support for removing properties was added to activesyncd. Is also applied to all other sources, just in case. The EDS contact backend needs to keep the X-EVOLUTION-FILE-AS property because EDS keeps adding it, which makes it impossible to test its removal.
2011-11-24 16:35:10 +01:00
* @param luids optional; if empty, then fill with luids (empty string for failed items);
* if not empty, then update instead of adding the items
testing: improved Client::Source::*::testImport Instead of aborting the test at the first item which fails to import, collect the error messages (from the exceptions), do the comparison of imported data against the reference data and then either report the import failures (if there were any) or the comparison failure (if that broke). The advantage is that a single run of the test shows all problems that exist.
2011-08-07 16:08:00 +02:00
* @return error string, empty for success
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
boost::function<std::string (ClientTest &, TestingSyncSource &, const ClientTestConfig &,
testing: added Source::*::testRemoveProperties This is primarily for ActiveSync where the test failed until support for removing properties was added to activesyncd. Is also applied to all other sources, just in case. The EDS contact backend needs to keep the X-EVOLUTION-FILE-AS property because EDS keeps adding it, which makes it impossible to test its removal.
2011-11-24 16:35:10 +01:00
const std::string &, std::string &, std::list<std::string> *)> m_import;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* a function which compares two files with items in the format used by "dump"
*
* @param fileA first file name
* @param fileB second file name
* @return true if the content of the files is considered equal
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
boost::function<bool (ClientTest &, const std::string &, const std::string &)> m_compare;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
client-test: added Sync::*::testExtensions One of the features of the Synthesis engine is that it can preserve properties locally which are not supported by the peer. "testExtensions" covers that, by updating all items on the server (via client B) and reimporting them as updates into client A. The data comparison then is done without the usual "allow server to drop data" simplifications in synccompare. This test is not enabled yet. "config.update" needs to be set for it, but doing so then trips over other changes introduced by servers, like for example re-encoding photos. Needs some more thoughts and testing...
2011-02-18 12:34:20 +01:00
* A file with test cases in the format expected by import and compare.
* The file should contain data as supported by the local storage.
*
* It is used in "Source::*::testImport" test, which verifies that
* the backend can import and export that data.
*
* It is also used in "Sync::*::testItems", which verifies that
* the peer can store and export it. Often local extensions are
* not supported by peers. This can be handled in different ways:
* - Patch synccompare to ignore such changes on a per-peer basis.
* - Create a <testcases>.<peer>.tem file in the src/testcases
nightly testing: renamed ical20/itodo20/vcard30/text, removed vcard21 from Evolution backend (BMC #14972) The distinction between vcard21 and vcard30 became mute in the Evolution backend a while ago. Both tests ended up using the vCard 3.0 Evolution tests data and the default uri for each server. This patch removes the vCard 2.1 special case. It also renames the tests and test data to reflect that they always were Evolution specific. The new naming convention, also applied to file, QtContacts, KCalExtended, XMLRPC, Maemo and Akonadi backends, is now <backend>_contact/event/task/memo, with eds/file/qt/kcal/maemo/kde as backend names. The reasoning is: - results in unique string (in particular no overlap with backend type names), easier to search for - underscore already used before (in contrast to hyphen) - no plural-s to keep the name shorter The Akonadi backend should be using its own test data instead of the Evolution ones.
2011-05-05 14:15:55 +02:00
* build directory where <testcases> is the string here ("eds_event.ics"),
client-test: added Sync::*::testExtensions One of the features of the Synthesis engine is that it can preserve properties locally which are not supported by the peer. "testExtensions" covers that, by updating all items on the server (via client B) and reimporting them as updates into client A. The data comparison then is done without the usual "allow server to drop data" simplifications in synccompare. This test is not enabled yet. "config.update" needs to be set for it, but doing so then trips over other changes introduced by servers, like for example re-encoding photos. Needs some more thoughts and testing...
2011-02-18 12:34:20 +01:00
* and <peer> the value of CLIENT_TEST_SERVER ("funambol").
* That file then will be used in testItems instead of the base
* version. See the src/Makefile.am for rules that maintain such files.
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_testcases;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* the item type normally used by the source (not used by the tests
* themselves; client-test.cpp uses it to initialize source configs)
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_type;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
ClientTest: enabling the test with virtual syncsource Virtual syncsource should be viewed as a single source by the synccontext while as a list of sub datasources for the LocalTest.
2009-12-16 07:43:08 +01:00
/**
* a list of sub configs separated via , if this is a super datastore
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
std::string m_subConfigs;
ClientTest: enabling the test with virtual syncsource Virtual syncsource should be viewed as a single source by the synccontext while as a list of sub datasources for the LocalTest.
2009-12-16 07:43:08 +01:00
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
/**
* TRUE if the source supports recovery from an interrupted
* synchronization. Enables the Client::Sync::*::Retry group
* of tests.
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
Bool m_retrySync;
Bool m_suspendSync;
Bool m_resendSync;
client-test: added Sync::*::testExtensions One of the features of the Synthesis engine is that it can preserve properties locally which are not supported by the peer. "testExtensions" covers that, by updating all items on the server (via client B) and reimporting them as updates into client A. The data comparison then is done without the usual "allow server to drop data" simplifications in synccompare. This test is not enabled yet. "config.update" needs to be set for it, but doing so then trips over other changes introduced by servers, like for example re-encoding photos. Needs some more thoughts and testing...
2011-02-18 12:34:20 +01:00
testing: added Source::*::testRemoveProperties This is primarily for ActiveSync where the test failed until support for removing properties was added to activesyncd. Is also applied to all other sources, just in case. The EDS contact backend needs to keep the X-EVOLUTION-FILE-AS property because EDS keeps adding it, which makes it impossible to test its removal.
2011-11-24 16:35:10 +01:00
/**
* Set this to a list of properties which must *not* be removed
* from the test items. Leave empty to disable the testRemoveProperties
* test. Test items must be in vCard 3.0/iCalendar 2.0 format.
*/
std::set<std::string> m_essentialProperties;
client-test: added Sync::*::testExtensions One of the features of the Synthesis engine is that it can preserve properties locally which are not supported by the peer. "testExtensions" covers that, by updating all items on the server (via client B) and reimporting them as updates into client A. The data comparison then is done without the usual "allow server to drop data" simplifications in synccompare. This test is not enabled yet. "config.update" needs to be set for it, but doing so then trips over other changes introduced by servers, like for example re-encoding photos. Needs some more thoughts and testing...
2011-02-18 12:34:20 +01:00
/**
* Set this to test if the source supports preserving local data extensions.
* Uses the "testcases" data. See Sync::*::testExtensions.
*
* The function must modify a single item such that re-importing
testing: fixes for Client::Sync::*::testExtensions Backends don't have access to ClientTest::update. Must provide a pointer to it in the test config => ClientTestConfig::genericUpdate. Manipulating N/FN is problematic because some peers support FN, some don't => better update or add a NOTE instead when dealing with vCards. Must also work for NOTE;CHARSET="UTF-8": test case, so the matching against properties in the item is very inprecise.
2011-06-15 15:50:18 +02:00
* it locally will be seen as updating it. It is empty by default
* because not all backends necessarily pass this test.
*
* genericUpdate works for vCard and iCalendar by updating FN, N, resp. SUMMARY
* and can be used as implementation of update.
client-test: added Sync::*::testExtensions One of the features of the Synthesis engine is that it can preserve properties locally which are not supported by the peer. "testExtensions" covers that, by updating all items on the server (via client B) and reimporting them as updates into client A. The data comparison then is done without the usual "allow server to drop data" simplifications in synccompare. This test is not enabled yet. "config.update" needs to be set for it, but doing so then trips over other changes introduced by servers, like for example re-encoding photos. Needs some more thoughts and testing...
2011-02-18 12:34:20 +01:00
*/
testing: cleaned up ClientTestConfig The memset/memcpy of the embedded boost::function instances inside the old ClientTestConfig was causing segfaults at the end of a client-test run if compiled with optimization. Therefore this commit turns ClientTestConfig into a proper class containing members which initialize themselves (Bool wrapper class, std::string), thus memset is no longer needed and used. Also added the standard m_ prefix. m_numItems is gone, was never set by any backend anyway and even expected to be consistent in one test. Now CLIENT_TEST_NUM_ITEMS is read by defNumItems() each time it is needed. Removed "const char *" strings from method parameters. This revealed that config.itemType (a const char *) was incorrectly passed to insert() where the boolean "relax" parameter should have been given. Replaced by "false" (= strict checking) even though the old code must have run with an implicit "true" (= relaxed checking). Let's see whether any tests fail now. (cherry-picked from commit 6399bd818173cd635b50a8315351ac2e31773b78)
2011-09-02 09:42:19 +02:00
boost::function<void (std::string &)> m_update;
boost::function<void (std::string &)> m_genericUpdate;
testing: added Client::Source::*::testLinkedSources The WebDAV backend must support different kinds of items in the same collection. The new testLinkedSources covers this by adding, updating and deleting an item of one kind and checking that other sources referencing the same database do not see these changes. This test must be activated for a specific source by adding links to other sources using the same database. A separate commit will do that for WebDAV.
2012-06-12 17:20:40 +02:00
/**
* A list of m_sourceName values of other ClientTestConfigs
* which share the same database. Normally, sources are tested in
* isolation, but for such linked sources we also need to test
* interdependencies, in particular regarding change tracking and
* item listing.
*/
std::list<std::string> m_linkedSources;
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable backends Install head files to a standard path, the remaining dependencies are synthesis and boost client-test is portable when ENABLE_MODULES is defined, no longer link to backends libraries. Add --enable-developer-mode, in which mode the backend scan path will be under current build directory for development purposes.
2009-09-02 05:13:10 +02:00
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* In addition to registering the sync source itself by creating an
* instance of RegisterSyncSource, configurations for testing it can
* also be registered. A sync source which supports more than one data
* exchange format can register one configuration for each format, but
* not registering any configuration is also okay.
*
CPPUnit header file dependency for backends (MB #9149) Congwu already removed the -DENABLE_INTEGRATION_TESTS, which caused the CPPUnit header include. This caused a problem in the nightly build, which compiles without --enable-integration-tests and then compiles client-test separately. Registering integration tests doesn't depend on CPPUnit headers or libs, only running them. Backends therefore should always register themselves for testing. This patch clarifies that in the comments and changes the Evolution and file backends accordingly.
2010-01-22 10:46:12 +01:00
* *Using* the registered tests depends on the CPPUnit test framework.
* *Registering* does not. Therefore backends should always register *
* *themselves for testing and leave it to the test runner
* "client-test" whether tests are really executed.
*
* Unit tests are different. They create hard dependencies on CPPUnit
* inside the code that contains them, and thus should be encapsulated
* inside #ifdef ENABLE_UNIT_TESTS checks.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*
* Sync sources have to work stand-alone without a full SyncClient
* configuration for all local tests. The minimal configuration prepared
* for the source includes:
* - a tracking node (as used f.i. by TrackingSyncSource) which
* points towards "~/.config/syncevolution/client-test-changes"
* - a unique change ID (as used f.i. by EvolutionContactSource)
* - a valid "evolutionsource" property in the config node, starting
* with the CLIENT_TEST_EVOLUTION_PREFIX env variable or (if that
* wasn't set) the "SyncEvolution_Test_" prefix
* - "evolutionuser/password" if CLIENT_TEST_EVOLUTION_USER/PASSWORD
* are set
*
* No other properties are set, which implies that currently sync sources
* which require further parameters cannot be tested.
*
* @warning There is a potential problem with the registration
* mechanism. Both the sync source tests as well as the CPPUnit tests
* derived from them are registrered when global class instances are
* initialized. If the RegisterTestEvolution instance in
* client-test-app.cpp is initialized *before* the sync source tests,
* then those won't show up in the test list. Currently the right
* order seems to be used, so everything works as expected.
*/
class RegisterSyncSourceTest
{
public:
testing: allow backends to register tests after main() Backends are now allowed to create RegisterSyncSourceTest instances with empty name. They will be ignored except that their init() method will be called after main() and before the list of source tests is used. This can be used to create additional RegisterSyncSourceTest instances at a time when the test of libsyncevolution is initialized. This is needed by the WebDAV backend, which has to instantiate sources and use the config system. That crashed when done before the ConfigProperty instances were initialized.
2012-06-12 17:26:09 +02:00
/**
* Invoked after all global constructors are run.
* May add further RegisterSyncSourceTests to the
* global registry.
*/
virtual void init() const {}
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* This call is invoked after setting up the config with default
* values for the test cases selected via the constructor's
nightly testing: renamed ical20/itodo20/vcard30/text, removed vcard21 from Evolution backend (BMC #14972) The distinction between vcard21 and vcard30 became mute in the Evolution backend a while ago. Both tests ended up using the vCard 3.0 Evolution tests data and the default uri for each server. This patch removes the vCard 2.1 special case. It also renames the tests and test data to reflect that they always were Evolution specific. The new naming convention, also applied to file, QtContacts, KCalExtended, XMLRPC, Maemo and Akonadi backends, is now <backend>_contact/event/task/memo, with eds/file/qt/kcal/maemo/kde as backend names. The reasoning is: - results in unique string (in particular no overlap with backend type names), easier to search for - underscore already used before (in contrast to hyphen) - no plural-s to keep the name shorter The Akonadi backend should be using its own test data instead of the Evolution ones.
2011-05-05 14:15:55 +02:00
* testCaseName parameter (one of eds_contact, eds_contact, eds_event, eds_task;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* see ClientTest in the Funambol client library for the current
* list).
*
* This call can then override any of the values or (if there
* are no predefined test cases) add them.
*
* The "type" property must select your sync source and the
* data format for the test.
*
* @retval config change any field whose default is not suitable
*/
virtual void updateConfig(ClientTestConfig &config) const = 0;
/**
* @param configName a unique string: the predefined names known by
* ClientTest::getTestData() are already used for the initial
* set of Evolution sync sources, for new sync sources
* build a string by combining them with the sync source name
nightly testing: renamed ical20/itodo20/vcard30/text, removed vcard21 from Evolution backend (BMC #14972) The distinction between vcard21 and vcard30 became mute in the Evolution backend a while ago. Both tests ended up using the vCard 3.0 Evolution tests data and the default uri for each server. This patch removes the vCard 2.1 special case. It also renames the tests and test data to reflect that they always were Evolution specific. The new naming convention, also applied to file, QtContacts, KCalExtended, XMLRPC, Maemo and Akonadi backends, is now <backend>_contact/event/task/memo, with eds/file/qt/kcal/maemo/kde as backend names. The reasoning is: - results in unique string (in particular no overlap with backend type names), easier to search for - underscore already used before (in contrast to hyphen) - no plural-s to keep the name shorter The Akonadi backend should be using its own test data instead of the Evolution ones.
2011-05-05 14:15:55 +02:00
* (e.g., "sqlite_eds_contact")
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* @param testCaseName a string recognized by ClientTest::getTestData() or an
* empty string if there are no predefined test cases
*/
RegisterSyncSourceTest(const string &configName,
const string &testCaseName);
virtual ~RegisterSyncSourceTest() {}
const string m_configName;
const string m_testCaseName;
testing: added Client::Source::*::testLinkedSources The WebDAV backend must support different kinds of items in the same collection. The new testLinkedSources covers this by adding, updating and deleting an item of one kind and checking that other sources referencing the same database do not see these changes. This test must be activated for a specific source by adding links to other sources using the same database. A separate commit will do that for WebDAV.
2012-06-12 17:20:40 +02:00
/**
* A list of m_configName values of other RegisterSyncSourceTest
* which share the same database. Normally, sources are tested in
* isolation, but for such linked sources we also need to test
* interdependencies, in particular regarding change tracking and
* item listing.
*/
std::list<std::string> m_linkedSources;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
class TestRegistry : public vector<const RegisterSyncSourceTest *>
{
public:
// TODO: using const RegisterSyncSourceTest * operator [] (int);
const RegisterSyncSourceTest * operator [] (const string &configName) const {
BOOST_FOREACH(const RegisterSyncSourceTest *test, *this) {
if (test->m_configName == configName) {
return test;
}
}
throw out_of_range(string("test config registry: ") + configName);
return NULL;
}
};
/**
* a container for Synthesis XML config fragments
*
* Backends can define their own field lists, profiles, datatypes and
* remote rules. The name of each of these entities have to be unique:
* either prefix each name with the name of the backend or coordinate
* with other developers (e.g. regarding shared field lists).
*
* To add new items, add them to the respective hash in your backend's
* getDatastoreXML() or getSynthesisInfo() implementation. Both
* methods have default implementations: getSynthesisInfo() is called
* by the default getDatastoreXML() to provide some details and
* provides them based on the "type" configuration option.
*
* The default config XML contains several predefined items:
* - field lists: contacts, calendar, Note, bookmarks
* - profiles: vCard, vCalendar, Note, vBookmark
* - datatypes: vCard21, vCard30, vCalendar10, iCalendar20,
* note10/11 (no difference except the versioning!),
* vBookmark10
* - remote rule: EVOLUTION
*
* These items do not appear in the hashes, so avoid picking the same
* names. The entries of each hash has to be a well-formed XML
* element, their keys the name encoded in each XML element.
*/
struct XMLConfigFragments {
class mapping : public std::map<std::string, std::string> {
public:
string join() {
string res;
size_t len = 0;
BOOST_FOREACH(const value_type &entry, *this) {
len += entry.second.size() + 1;
}
res.reserve(len);
BOOST_FOREACH(const value_type &entry, *this) {
res += entry.second;
res += "\n";
}
return res;
}
} m_fieldlists,
m_profiles,
m_datatypes,
m_remoterules;
};
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
/**
* used in SyncSource::Operations post-operation signal
*/
enum OperationExecution {
OPERATION_SKIPPED, /**< operation was skipped because pre-operation slot threw an exception */
OPERATION_EXCEPTION, /**< operation itself failed with an exception (may also return error code) */
OPERATION_FINISHED, /**< operation finished normally (but might have returned an error code) */
OPERATION_EMPTY /**< operation not implemented */
};
/**
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
* Helper class for looking up a pending operation by a Synthesis parameter.
* KeyH (add, replace) and item ID (delete) are supported.
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
*/
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
template<class A1> struct KeyConverter;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
/**
* For KeyH we make the assumption that the key exists as long
* as the pending operation, and thus its address can be used as
* unique identifier for the operation.
*/
template<> struct KeyConverter<sysync::KeyH>
{
typedef void * key_type;
static key_type toKey(sysync::KeyH key) { return static_cast<void *>(key); }
};
/**
* For cItemID we just use the item ID as string.
*/
template<> struct KeyConverter<sysync::cItemID>
{
typedef std::string key_type;
static key_type toKey(sysync::cItemID id) { return id->item; }
};
/**
* To be returned by a function wrapped by OperationWrapper
* when the function is not done yet and wants to be called again
* for the same item.
*/
template <class F> class ContinueOperation : public boost::function<F>
{
public:
ContinueOperation()
{}
ContinueOperation(const boost::function<F> &callback) :
boost::function<F>(callback)
{}
};
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
/**
* Interface expected by SyncSourceBase helper class.
* Needed to break a cyclic dependency.
*/
class SyncSourceName
{
public:
/**
* the name of the sync source (for example, "addressbook"),
* unique in the context of its own configuration
**/
virtual std::string getName() const { return "uninitialized SyncSourceBase"; }
/**
* the name of the sync source as it should be displayed to users
* in debug messages; typically the same as getName(), but may
* also include a context ("@foobar/addressbook") to disambiguate
* the name when "addressbook" is used multiple times in a sync (as
* with local sync)
*/
virtual std::string getDisplayName() const { return "uninitialized SyncSourceBase"; }
};
/**
* Implements the "call all slots, error if any failed" semantic of
* the pre- and post-signals described below.
*/
class OperationSlotInvoker {
SyncSourceName &m_source;
public:
OperationSlotInvoker(SyncSourceName &source) :
m_source(source)
{}
typedef sysync::TSyError result_type;
template<typename InputIterator>
result_type operator() (InputIterator first, InputIterator last) const
{
result_type res = sysync::LOCERR_OK;
while (first != last) {
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
SyncMLStatus status;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
try {
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
status = *first;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
} catch (...) {
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
status = Exception::handle(m_source.getDisplayName());
}
if (res == sysync::LOCERR_OK) {
res = static_cast<result_type>(status);
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
}
++first;
}
return res;
}
};
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
/**
* Helper class, needs to be specialized based on number of parameters
* and return type.
*/
template<class F, int arity, class R> class OperationWrapperSwitch;
/** one parameter, sysync::TSyError type */
template<class F> class OperationWrapperSwitch<F, 0, sysync::TSyError>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
/**
* The pre-signal is invoked with the same parameters as
* the operations, plus a reference to the sync source as
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
* initial parameter. Slots may return something other than
* STATUS_OK or throw exceptions, which
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
* will skip the actual implementation. However, all slots
* will be invoked exactly once even if one of them throws
* an exception. The result of the operation then is the
* error code extracted from the first exception (see
* OperationSlotInvoker).
*/
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PreSignal;
/**
* The post-signal is invoked exactly once, regardless
* whether the implementation was skipped, executed or
* doesn't exist at all. This information is passed as the
* second parameter, followed by the result of the
* operation or the pre-signals, followed by the
* parameters of the operation.
*
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
* As with the pre-signal, any slot may return something other
* than STATUS_OK or throw an exception
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
* to override the final result, but this won't interrupt
* calling the rest of the slots.
*/
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PostSignal;
/**
* invokes signals and implementation of operation,
* combines all return codes into one
*/
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () () const throw ()
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
sysync::TSyError res;
OperationExecution exec;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = m_pre(dynamic_cast<SyncSource &>(m_source));
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (m_operation) {
try {
res = m_operation();
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
/**
* Anyone may connect code to the signals via
* getOperations().getPre/PostSignal(), although strictly
* speaking this modifies the behavior of the
* implementation.
*/
SyncSource: simplify getPre/PostSignal() Const-casting the member references is easier (= less code) because we have a typedef for them and we can omit the access via "this".
2013-06-05 16:56:21 +02:00
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
PreSignal m_pre;
PostSignal m_post;
};
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
template<class F> class OperationWrapperSwitch<F, 1, sysync::TSyError>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
arg1_type a1),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PostSignal;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1) const throw ()
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
sysync::TSyError res;
OperationExecution exec;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = m_pre(dynamic_cast<SyncSource &>(m_source), a1);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (m_operation) {
try {
res = m_operation(a1);
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
SyncSource: simplify getPre/PostSignal() Const-casting the member references is easier (= less code) because we have a typedef for them and we can omit the access via "this".
2013-06-05 16:56:21 +02:00
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
PreSignal m_pre;
PostSignal m_post;
};
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
template<class F, class V> class OperationWrapperSwitch<F, 1, V>
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1),
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
arg1_type a1),
OperationSlotInvoker> PostSignal;
typedef KeyConverter<arg1_type> Converter;
typedef ContinueOperation<sysync::TSyError (arg1_type)> Continue;
typedef std::map<typename Converter::key_type, Continue> Pending;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1) const throw ()
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
{
sysync::TSyError res;
OperationExecution exec;
// Marking m_pending "volatile" didn't work, find() not defined for that.
typename Pending::iterator it = const_cast<Pending &>(m_pending).find(Converter::toKey(a1));
bool continuing = it != m_pending.end();
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = continuing ? sysync::LOCERR_OK : m_pre(dynamic_cast<SyncSource &>(m_source), a1);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (continuing) {
res = it->second(a1);
if (res != sysync::LOCERR_AGAIN) {
const_cast<Pending &>(m_pending).erase(it);
}
} else if (m_operation) {
try {
V newres = m_operation(a1);
sysync::TSyError *completed = boost::get<sysync::TSyError>(&newres);
if (completed) {
res = *completed;
} else {
res = sysync::LOCERR_AGAIN;
Continue cont = boost::get<Continue>(newres);
const_cast<Pending &>(m_pending).insert(std::make_pair(Converter::toKey(a1), cont));
}
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
if (res != sysync::LOCERR_AGAIN) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
PreSignal m_pre;
PostSignal m_post;
Pending m_pending;
};
template<class F> class OperationWrapperSwitch<F, 2, sysync::TSyError>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
typedef typename boost::function<F>::arg2_type arg2_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1, arg2_type a2),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
arg1_type a1, arg2_type a2),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PostSignal;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1, arg2_type a2) const throw ()
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
sysync::TSyError res;
OperationExecution exec;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = m_pre(dynamic_cast<SyncSource &>(m_source), a1, a2);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (m_operation) {
try {
res = m_operation(a1, a2);
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1, a2);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
SyncSource: simplify getPre/PostSignal() Const-casting the member references is easier (= less code) because we have a typedef for them and we can omit the access via "this".
2013-06-05 16:56:21 +02:00
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
PreSignal m_pre;
PostSignal m_post;
};
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
template<class F, class V> class OperationWrapperSwitch<F, 2, V>
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
typedef typename boost::function<F>::arg2_type arg2_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1, arg2_type a2),
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
arg1_type a1, arg2_type a2),
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
OperationSlotInvoker> PostSignal;
typedef KeyConverter<arg1_type> Converter;
typedef ContinueOperation<sysync::TSyError (arg1_type, arg2_type)> Continue;
typedef std::map<typename Converter::key_type, Continue> Pending;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1, arg2_type a2) const throw ()
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
{
sysync::TSyError res;
OperationExecution exec;
// Marking m_pending "volatile" didn't work, find() not defined for that.
typename Pending::iterator it = const_cast<Pending &>(m_pending).find(Converter::toKey(a1));
bool continuing = it != m_pending.end();
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = continuing ? sysync::LOCERR_OK : m_pre(dynamic_cast<SyncSource &>(m_source), a1, a2);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (continuing) {
res = it->second(a1, a2);
if (res != sysync::LOCERR_AGAIN) {
const_cast<Pending &>(m_pending).erase(it);
}
} else if (m_operation) {
try {
V newres = m_operation(a1, a2);
sysync::TSyError *completed = boost::get<sysync::TSyError>(&newres);
if (completed) {
res = *completed;
} else {
res = sysync::LOCERR_AGAIN;
Continue cont = boost::get<Continue>(newres);
const_cast<Pending &>(m_pending).insert(std::make_pair(Converter::toKey(a1), cont));
}
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
if (res != sysync::LOCERR_AGAIN) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1, a2);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
PreSignal m_pre;
PostSignal m_post;
Pending m_pending;
};
template<class F> class OperationWrapperSwitch<F, 3, sysync::TSyError>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
typedef typename boost::function<F>::arg2_type arg2_type;
typedef typename boost::function<F>::arg3_type arg3_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1, arg2_type a2, arg3_type a3),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
arg1_type a1, arg2_type a2, arg3_type a3),
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
OperationSlotInvoker> PostSignal;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1, arg2_type a2, arg3_type a3) const throw ()
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
sysync::TSyError res;
OperationExecution exec;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = m_pre(dynamic_cast<SyncSource &>(m_source), a1, a2, a3);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (m_operation) {
try {
res = m_operation(a1, a2, a3);
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1, a2, a3);
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
SyncSource: simplify getPre/PostSignal() Const-casting the member references is easier (= less code) because we have a typedef for them and we can omit the access via "this".
2013-06-05 16:56:21 +02:00
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
PreSignal m_pre;
PostSignal m_post;
};
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
template<class F, class V> class OperationWrapperSwitch<F, 3, V>
{
public:
typedef sysync::TSyError result_type;
typedef boost::function<F> OperationType;
typedef typename boost::function<F>::arg1_type arg1_type;
typedef typename boost::function<F>::arg2_type arg2_type;
typedef typename boost::function<F>::arg3_type arg3_type;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, arg1_type a1, arg2_type a2, arg3_type a3),
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
OperationSlotInvoker> PreSignal;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
typedef boost::signals2::signal<SyncMLStatus (SyncSource &, OperationExecution, sysync::TSyError,
arg1_type a1, arg2_type a2, arg3_type a3),
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
OperationSlotInvoker> PostSignal;
typedef KeyConverter<arg1_type> Converter;
typedef ContinueOperation<sysync::TSyError (arg1_type, arg2_type, arg3_type)> Continue;
typedef std::map<typename Converter::key_type, Continue> Pending;
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError operator () (arg1_type a1, arg2_type a2, arg3_type a3) const throw ()
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
{
sysync::TSyError res;
OperationExecution exec;
// Marking m_pending "volatile" didn't work, find() not defined for that.
typename Pending::iterator it = const_cast<Pending &>(m_pending).find(Converter::toKey(a1));
bool continuing = it != m_pending.end();
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = continuing ? sysync::LOCERR_OK : m_pre(dynamic_cast<SyncSource &>(m_source), a1, a2, a3);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (res != sysync::LOCERR_OK) {
exec = OPERATION_SKIPPED;
} else {
if (continuing) {
res = it->second(a1, a2, a3);
if (res != sysync::LOCERR_AGAIN) {
const_cast<Pending &>(m_pending).erase(it);
}
} else if (m_operation) {
try {
V newres = m_operation(a1, a2, a3);
sysync::TSyError *completed = boost::get<sysync::TSyError>(&newres);
if (completed) {
res = *completed;
} else {
res = sysync::LOCERR_AGAIN;
Continue cont = boost::get<Continue>(newres);
const_cast<Pending &>(m_pending).insert(std::make_pair(Converter::toKey(a1), cont));
}
exec = OPERATION_FINISHED;
} catch (...) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
res = Exception::handle(m_source.getDisplayName());
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
exec = OPERATION_EXCEPTION;
}
} else {
res = sysync::LOCERR_NOTIMP;
exec = OPERATION_EMPTY;
}
}
if (res != sysync::LOCERR_AGAIN) {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
sysync::TSyError newres = m_post(dynamic_cast<SyncSource &>(m_source), exec, res, a1, a2, a3);
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
if (newres != sysync::LOCERR_OK) {
res = newres;
}
}
return res == STATUS_FATAL ? STATUS_DATASTORE_FAILURE : res;
}
PreSignal &getPreSignal() const { return const_cast<PreSignal &>(m_pre); }
PostSignal &getPostSignal() const { return const_cast<PostSignal &>(m_post); }
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapperSwitch(SyncSourceName &source) :
m_source(source),
m_pre(OperationSlotInvoker(source)),
m_post(OperationSlotInvoker(source))
{
}
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
protected:
OperationType m_operation;
private:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
SyncSourceName &m_source;
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
PreSignal m_pre;
PostSignal m_post;
Pending m_pending;
};
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
/**
* This mimics a boost::function with the same signature. The function
* signature F must have a sysync::TSyError error return code, as in most
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
* of the Synthesis DB API, or a boost::variant of sysync::TSyError and
* ContinueOperation<F>.
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
*
* Specializations of this class for operations with different number
* of parameters provide a call operator which invokes a pre- and
* post-signal around the actual implementation. See
* OperationWrapperSwitch<F, 0> for details.
*
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
* If the function returns a variant with a ContinueOperation<F> inside,
* the OperationWrapper will store that callback for the current
* set of parameters (currently using only the first one as key),
* then when called again, skip the pre-signal and invoke the callback
* instead of the original operation. That callback may return LOCERR_AGAIN
* to request being called again the same way. The post-signal is
* called when the operation finally completes.
*
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
* Additional operations could be wrapped by providing more
* specializations (different return code, more parameters). The
* number or parameters in the operation cannot exceed six, because
* adding three more parameters in the post-signal would push the
* total number of parameters in that signal beyond the limit of nine
* supported arguments in boost::signals2/boost::function.
*/
template<class F> class OperationWrapper :
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
public OperationWrapperSwitch<F, boost::function<F>::arity, typename boost::function<F>::result_type>
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
{
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
typedef OperationWrapperSwitch<F, boost::function<F>::arity, typename boost::function<F>::result_type> inherited;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
public:
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
OperationWrapper(SyncSourceName &source): inherited(source) {}
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
/** operation implemented? */
operator bool () const { return inherited::m_operation; }
/**
* Only usable by derived classes via read/write m_operations:
* sets the actual implementation of the operation.
*/
void operator = (const boost::function<F> &operation)
{
inherited::m_operation = operation;
}
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* abstract base class for SyncSource with some common functionality
* and no data
*
* Used to implement and call that functionality in multiple derived
* classes, including situations where a derived class is derived from
* this base via different intermediate classes, therefore the
* need to keep it abstract.
*/
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
class SyncSourceBase : public SyncSourceName {
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
public:
virtual ~SyncSourceBase() {}
/**
* Convenience function, to be called inside a catch() block of
* (or for) the sync source.
*
* Rethrows the exception to determine what it is, then logs it
* as an error and returns a suitable error code (usually a general
* STATUS_DATASTORE_FAILURE).
phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744) When deleting an item on phone and locally, the next sync fails with ERROR messages about "object not found". This has several reasons: - libsynthesis super data store attempts to read items which may or may not exist (triggers ERROR message) - it checks for 404 but Evolution backends only return a generic database error (causes sync to fail) It turned out that ReadItem and DeleteItem are expected to return a 404 status when the requested item does not exist. This patch documents that (only in the TrackingSyncSource, though), adds tests and fixes EDS, WebDAV, file and sqlite backends accordingly. This patch also suppresses the 404 error logging inside DeleteItem(), while still returning that error code to the Synthesis engine. Not logging that particular situation is consistent with the previous SyncEvolution behavior of silently returning successfully when there wasn't anything to delete. In addition, more recent libsynthesis versions also no longer do a ReadItem() call to test for existence. That would still trigger a spurious (albeit now harmless) ERROR message.
2011-10-24 18:05:30 +02:00
*
* @param flags influence behavior of the method
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744) When deleting an item on phone and locally, the next sync fails with ERROR messages about "object not found". This has several reasons: - libsynthesis super data store attempts to read items which may or may not exist (triggers ERROR message) - it checks for 404 but Evolution backends only return a generic database error (causes sync to fail) It turned out that ReadItem and DeleteItem are expected to return a 404 status when the requested item does not exist. This patch documents that (only in the TrackingSyncSource, though), adds tests and fixes EDS, WebDAV, file and sqlite backends accordingly. This patch also suppresses the 404 error logging inside DeleteItem(), while still returning that error code to the Synthesis engine. Not logging that particular situation is consistent with the previous SyncEvolution behavior of silently returning successfully when there wasn't anything to delete. In addition, more recent libsynthesis versions also no longer do a ReadItem() call to test for existence. That would still trigger a spurious (albeit now harmless) ERROR message.
2011-10-24 18:05:30 +02:00
SyncMLStatus handleException(HandleExceptionFlags flags = HANDLE_EXCEPTION_FLAGS_NONE);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* throw an exception after an operation failed
*
* output format: <source name>: <action>: <error string>
*
* @param action a string describing the operation or object involved
* @param error the errno error code for the failure
*/
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
void throwError(const SourceLocation &where, const string &action, int error) SE_NORETURN;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* throw an exception after an operation failed and
* remember that this instance has failed
*
* output format: <source name>: <failure>
*
* @param action a string describing what was attempted *and* how it failed
*/
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
void throwError(const SourceLocation &where, const string &failure) SE_NORETURN;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncSource/Context: throwError() with specific status So far throwError() always resulted in a STATUS_FATAL. Now the caller can specify a specific error code.
2011-02-10 14:14:14 +01:00
/**
* throw an exception with a specific status code after an operation failed and
* remember that this instance has failed
*
* output format: <source name>: <failure>
*
* @param status a more specific status code; other throwError() variants use STATUS_FATAL
* @param action a string describing what was attempted *and* how it failed
*/
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
void throwError(const SourceLocation &where, SyncMLStatus status, const string &failure) SE_NORETURN;
SyncSource/Context: throwError() with specific status So far throwError() always resulted in a STATUS_FATAL. Now the caller can specify a specific error code.
2011-02-10 14:14:14 +01:00
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* The Synthesis engine only counts items which are deleted by the
* peer. Items deleted locally at the start of a
* refresh-from-server sync are not counted (and cannot be counted
* in all cases).
*
* Sync sources which want to have those items included in the
* sync statistics should count *all* deleted items using these
files and classes renamed, include statements cleaned up The intention is to get rid of the historic and inconsistent naming of some classes and their corresponding files: * EvolutionSyncClient = class derived from Funambol's SyncClient, * SyncEvolutionConfig = SyncEvolution's config With the strict 'namespace SyncEvo' and the syncevo/ path prefix for most header files it is no longer necessary to have "SyncEvolution" or "Evolution" in the names. This patch thus renames as follows: EvolutionSyncClient => SyncContext EvolutionSmartPtr => SmartPtr SyncEvolutionCmdline => Cmdline SyncEvolutionConfig => SyncConfig SyncEvolutionUtil => util The former EvolutionSyncClient always had a role that went beyond just running a sync, for example it also provided config access. With the upcoming server support it also won't be just a client. Thus the new name "SyncContext". The 'syncevo/' prefix is used throughout the code now. removed whenever the prefix made it clear that the file belongs to SyncEvolution. This helps finding incorrect include paths. Quotes should be used exclusively for SyncEvolution files which don't have a specific prefix yet (test.h, config.h) to help identifying them.
2009-10-05 14:49:32 +02:00
* methods. SyncContext will use this number for
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* refresh-from-server syncs.
*/
/**@{*/
virtual long getNumDeleted() const = 0;
virtual void setNumDeleted(long num) = 0;
virtual void incrementNumDeleted() = 0;
/**@}*/
/**
* Return Synthesis <datastore> XML fragment for this sync source.
* Must *not* include the <datastore> element; it is created by
* the caller.
*
* The default implementation returns a configuration for the
* SynthesisDBPlugin, which invokes SyncSource::Operations. Items
* are exchanged with the SyncsSource in the format defined by
* getSynthesisInfo(). The format used with the SyncML side is
* negotiated via the peer's capabilities, with the type defined
* in the configuration being the preferred one of the data store.
*
files and classes renamed, include statements cleaned up The intention is to get rid of the historic and inconsistent naming of some classes and their corresponding files: * EvolutionSyncClient = class derived from Funambol's SyncClient, * SyncEvolutionConfig = SyncEvolution's config With the strict 'namespace SyncEvo' and the syncevo/ path prefix for most header files it is no longer necessary to have "SyncEvolution" or "Evolution" in the names. This patch thus renames as follows: EvolutionSyncClient => SyncContext EvolutionSmartPtr => SmartPtr SyncEvolutionCmdline => Cmdline SyncEvolutionConfig => SyncConfig SyncEvolutionUtil => util The former EvolutionSyncClient always had a role that went beyond just running a sync, for example it also provided config access. With the upcoming server support it also won't be just a client. Thus the new name "SyncContext". The 'syncevo/' prefix is used throughout the code now. removed whenever the prefix made it clear that the file belongs to SyncEvolution. This helps finding incorrect include paths. Quotes should be used exclusively for SyncEvolution files which don't have a specific prefix yet (test.h, config.h) to help identifying them.
2009-10-05 14:49:32 +02:00
* See SyncContext::getConfigXML() for details about
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* predefined <datatype> entries that can be referenced here.
*
* @retval xml put content of <datastore>...</datastore> here
* @retval fragments the necessary definitions for the datastore have to be added here
*/
virtual void getDatastoreXML(string &xml, XMLConfigFragments &fragments);
/**
* Synthesis <datatype> name which matches the format used
* for importing and exporting items (exportData()).
* This is not necessarily the same format that is given
* to the Synthesis engine. If this internal format doesn't
* have a <datatype> in the engine, then an empty string is
* returned.
*/
virtual string getNativeDatatypeName();
/**
* return Synthesis API pointer, if one currently is available
* (between SyncEvolution_Module_CreateContext() and
* SyncEvolution_Module_DeleteContext())
*/
Synthesis API: move utility code to read/write keys into SDKInterface The new SDKInterface wraps the underlying SDK_Interface pointer in a slightly nicer, more C++ friendly API (methods instead of function pointers, dynamic allocation of buffer).
2009-08-13 17:22:45 +02:00
virtual SDKInterface *getSynthesisAPI() const = 0;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
/**
* Prepare the sync source for usage inside a SyncML server. To
* be called directly after creating the source, if at all.
*/
virtual void enableServerMode() = 0;
virtual bool serverModeEnabled() const = 0;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* The optional operations.
*
* All of them are guaranteed to happen between open() and
* close().
*
* They are all allowed to throw exceptions: the operations called
* by SyncEvolution then abort whatever SyncEvolution was doing
* and end in the normal exception handling. For the Synthesis
* operations, the bridge code in SynthesisDBPlugin code catches
* exceptions, logs them and translates them into Synthesis error
* codes, which are returned to the Synthesis engine.
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
*
* Monitoring of most DB operations is possible via the pre- and
* post-signals managed by OperationWrapper.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
struct Operations {
SyncSource: add source name to all exception handling Not all exceptions thrown while executing a source operation contain the source name. SyncSource::throwError() does that, but SE_THROW() as used in helper code does not. It is better to add the source name as logging prefix. The other advantage is that all lines will have the prefix, not just the first one. The SyncSource operations need access to the SyncSource class which contains them to access the display name of the SyncSource instance. A positive a side effect of telling the wrappers about the instance at construction time is that the caller no longer has to pass the source reference. This change allows removing the SyncSource::throwError() special cases, which completes the transition towards having correct source code location information for all exceptions.
2014-04-03 12:09:04 +02:00
Operations(SyncSourceName &source);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
* The caller determines where item data is stored (m_dirname)
* and where meta information about them (m_node). The callee
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
* then can use both arbitrarily. As an additional hint,
* m_mode specifies why and when the backup is made, which
* is useful to determine whether information can be reused.
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
*/
struct BackupInfo {
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
enum Mode {
BACKUP_BEFORE, /**< directly at start of sync */
BACKUP_AFTER, /**< directly after sync */
BACKUP_OTHER
} m_mode;
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
string m_dirname;
boost::shared_ptr<ConfigNode> m_node;
BackupInfo() {}
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
BackupInfo(Mode mode,
const string &dirname,
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
const boost::shared_ptr<ConfigNode> &node) :
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
m_mode(mode),
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
m_dirname(dirname),
m_node(node)
{}
};
struct ConstBackupInfo {
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
BackupInfo::Mode m_mode;
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
string m_dirname;
boost::shared_ptr<const ConfigNode> m_node;
ConstBackupInfo() {}
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
ConstBackupInfo(BackupInfo::Mode mode,
const string &dirname,
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
const boost::shared_ptr<const ConfigNode> &node) :
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
m_mode(mode),
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
m_dirname(dirname),
m_node(node)
{}
};
/**
* Dump all data from source unmodified into the given backup location.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* Information about the created backup is added to the
* report.
*
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
* Required for the backup/restore functionality in
* SyncEvolution, not for syncing itself. But typically it is
* called before syncing (can be turned off by users), so
* implementations can reuse the information gathered while
* making a backup in later operations.
*
* @param previous the most recent backup, empty m_dirname if none
* @param next the backup which is to be created, directory and node are empty
* @param report to be filled with information about backup (number of items, etc.)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
typedef void (BackupData_t)(const ConstBackupInfo &oldBackup,
const BackupInfo &newBackup,
BackupReport &report);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
boost::function<BackupData_t> m_backupData;
/**
* Restore database from data stored in backupData().
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
* If possible don't touch items which are the same as in the
* backup, to mimimize impact on future incremental syncs.
*
* @param oldBackup the backup which is to be restored
* @param dryrun pretend to restore and fill in report, without
* actually touching backend data
* @param report to be filled with information about restore
* (number of total items and changes)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
typedef void (RestoreData_t)(const ConstBackupInfo &oldBackup,
bool dryrun,
SyncSourceReport &report);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
boost::function<RestoreData_t> m_restoreData;
/**
* initialize information about local changes and items
* as in beginSync() with all parameters set to true,
* but without changing the state of the underlying database
*
* This method will be called to check for local changes without
* actually running a sync, so there is no matching end call.
*
* There might be sources which don't support non-destructive
* change tracking (in other words, checking changes permanently
* modifies the state of the source and cannot be repeated).
* Such sources should leave the functor empty.
*/
typedef void (CheckStatus_t)(SyncSourceReport &local);
boost::function<CheckStatus_t> m_checkStatus;
SyncSource API: added m_isEmpty operation (MB #7708) The current solution of checking for empty sources by looking at the "before" database dump is a hack which fails if creating that backup was disabled. It also prevents delaying the dump until after the start of the session, because the information must be available before starting the session, so that the XML config can be created with slow sync check enabled if needed. This patch adds a new operation which backends must implement if they want to provide the "is empty" information for the slow sync detection. This is optional. If the information is not available, slow sync detection is always on, even when not strictly needed.
2010-02-16 20:11:16 +01:00
/**
* A quick check whether the source currently has data.
*
* If this cannot be determined easily, don't provide the
* operation. The information is currently only used to
* determine whether a slow sync should be allowed. If
* the operation is not provided, the assumption is that
* there is local data, which disables the "allow slow
* sync for empty databases" heuristic and forces the user
* to choose.
*/
typedef bool (IsEmpty_t)();
boost::function<IsEmpty_t> m_isEmpty;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Synthesis DB API callbacks. For documentation see the
* Synthesis API specification (PDF and/or sync_dbapi.h).
*
* Implementing this is necessary for SyncSources which want
* to be part of a sync session.
*/
/**@{*/
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (const char *, const char *)> StartDataRead_t;
StartDataRead_t m_startDataRead;
SyncSource::Operations: added callback for starting to use source The new m_startAccess is called before the source's m_startDataRead and thus marks the point where a source is used for the first time during a sync. This is necessary for initializing sources in a server on demand. Because this happens inside SyncContext, at least callbacks must be possible for outside classes. Setting the other operations is still limited to derived classes.
2010-02-10 17:43:02 +01:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError ()> EndDataRead_t;
EndDataRead_t m_endDataRead;
SyncSource::Operations: added callback for starting to use source The new m_startAccess is called before the source's m_startDataRead and thus marks the point where a source is used for the first time during a sync. This is necessary for initializing sources in a server on demand. Because this happens inside SyncContext, at least callbacks must be possible for outside classes. Setting the other operations is still limited to derived classes.
2010-02-10 17:43:02 +01:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError ()> StartDataWrite_t;
StartDataWrite_t m_startDataWrite;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
typedef OperationWrapper<sysync::TSyError (sysync::cItemID aID, sysync::ItemID updID)> FinalizeLocalID_t;
FinalizeLocalID_t m_finalizeLocalID;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (bool success, char **newToken)> EndDataWrite_t;
EndDataWrite_t m_endDataWrite;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/** the SynthesisDBPlugin is configured so that this operation
doesn't have to (and cannot) return the item data */
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::ItemID aID,
sysync::sInt32 *aStatus, bool aFirst)> ReadNextItem_t;
ReadNextItem_t m_readNextItem;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::cItemID aID, sysync::KeyH aItemKey)> ReadItemAsKey_t;
ReadItemAsKey_t m_readItemAsKey;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
typedef ContinueOperation<sysync::TSyError (sysync::KeyH aItemKey, sysync::ItemID newID)> InsertItemAsKeyContinue_t;
typedef boost::variant<sysync::TSyError, InsertItemAsKeyContinue_t> InsertItemAsKeyResult_t;
typedef OperationWrapper<InsertItemAsKeyResult_t (sysync::KeyH aItemKey, sysync::ItemID newID)> InsertItemAsKey_t;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
InsertItemAsKey_t m_insertItemAsKey;
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
typedef ContinueOperation<sysync::TSyError (sysync::KeyH aItemKey, sysync::cItemID aID, sysync::ItemID updID)> UpdateItemAsKeyContinue_t;
typedef boost::variant<sysync::TSyError, UpdateItemAsKeyContinue_t> UpdateItemAsKeyResult_t;
typedef OperationWrapper<UpdateItemAsKeyResult_t (sysync::KeyH aItemKey, sysync::cItemID aID, sysync::ItemID updID)> UpdateItemAsKey_t;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
UpdateItemAsKey_t m_updateItemAsKey;
SyncSource: optional support for asynchronous insert/update/delete The wrapper around the actual operation checks if the operation returned an error or result code (traditional behavior). If not, it expects a ContinueOperation instance, remembers it and calls it when the same operation gets called again for the same item. For add/insert, "same item" is detected based on the KeyH address, which must not change. For delete, the item local ID is used. Pre- and post-signals are called exactly once, before the first call and after the last call of the item. ContinueOperation is a simple boost::function pointer for now. The Synthesis engine itself is not able to force completion of the operation, it just polls. This can lead to many empty messages with just an Alert inside, thus triggering the "endless loop" protection, which aborts the sync. We overcome this limitation in the SyncEvolution layer above the Synthesis engine: first, we flush pending operations before starting network IO. This is a good place to batch together all pending operations. Second, to overcome the "endless loop" problem, we force a waiting for completion if the last message already was empty. If that happened, we are done with items and should start sending our responses. Binding a function which returns the traditional TSyError still works because it gets copied transparently into the boost::variant that the wrapper expects, so no other code in SyncSource or backends needs to be adapted. Enabling the use of LOCERR_AGAIN in the utility classes and backends will follow in the next patches.
2013-06-05 17:22:00 +02:00
typedef ContinueOperation<sysync::TSyError (sysync::cItemID aID)> DeleteItemContinue_t;
typedef boost::variant<sysync::TSyError, DeleteItemContinue_t> DeleteItemResult_t;
typedef OperationWrapper<DeleteItemResult_t (sysync::cItemID aID)> DeleteItem_t;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
DeleteItem_t m_deleteItem;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**@}*/
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
/**
* Synthesis administration callbacks. For documentation see the
* Synthesis API specification (PDF and/or sync_dbapi.h).
*
* Implementing this is *optional* in clients. In the Synthesis client
* engine, the "binfiles" module provides these calls without SyncEvolution
* doing anything.
*
* In the Synthesis server engine, the
* SyncSource::enableServerMode() call must install an
* implementation, like the one from SyncSourceAdmin.
*/
/**@{*/
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (const char *aLocDB,
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
const char *aRemDB,
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
char **adminData)> LoadAdminData_t;
LoadAdminData_t m_loadAdminData;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (const char *adminData)> SaveAdminData_t;
SaveAdminData_t m_saveAdminData;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
// not currently wrapped because it has a different return type;
// templates could be adapted to handle that
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
typedef bool (ReadNextMapItem_t)(sysync::MapID mID, bool aFirst);
boost::function<ReadNextMapItem_t> m_readNextMapItem;
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::cMapID mID)> InsertMapItem_t;
InsertMapItem_t m_insertMapItem;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::cMapID mID)> UpdateMapItem_t;
UpdateMapItem_t m_updateMapItem;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::cMapID mID)> DeleteMapItem_t;
DeleteMapItem_t m_deleteMapItem;
SyncSource API: enable implementation of Synthesis Blobs (MB #2425) This patch allows SyncSources to implement the Synthesis Blob API. A reference implementation will be added separately.
2010-03-04 13:45:44 +01:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
// not wrapped, too many parameters
typedef boost::function<sysync::TSyError (sysync::cItemID aID, const char *aBlobID,
void **aBlkPtr, size_t *aBlkSize,
size_t *aTotSize,
bool aFirst, bool *aLast)> ReadBlob_t;
ReadBlob_t m_readBlob;
SyncSource API: enable implementation of Synthesis Blobs (MB #2425) This patch allows SyncSources to implement the Synthesis Blob API. A reference implementation will be added separately.
2010-03-04 13:45:44 +01:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef boost::function<sysync::TSyError (sysync::cItemID aID, const char *aBlobID,
void *aBlkPtr, size_t aBlkSize,
size_t aTotSize,
bool aFirst, bool aLast)> WriteBlob_t;
WriteBlob_t m_writeBlob;
SyncSource API: enable implementation of Synthesis Blobs (MB #2425) This patch allows SyncSources to implement the Synthesis Blob API. A reference implementation will be added separately.
2010-03-04 13:45:44 +01:00
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
typedef OperationWrapper<sysync::TSyError (sysync::cItemID aID, const char *aBlobID)> DeleteBlob_t;
DeleteBlob_t m_deleteBlob;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
/**@}*/
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
/**
* Read-only access to operations.
*/
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
virtual const Operations &getOperations() const = 0;
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
/**
* Start flushing item modifications which were not executed right
* away. Item modifications (add/update/delete) can be delayed by
* returning LOCERR_AGAIN or, when using for example
* SyncSourceSerialize aka TrackingSyncSource, by returning a "check"
* function instead of the final result.
*
* The sync engine calls this method after processing each incoming
* SyncML message.
*/
virtual void flushItemChanges() {}
/**
* Called after flush() to ensure that all pending modifications
* have completed. Called when the engine needs the results.
*
* Called by the sync engine when the SyncML peer ran out of new
* item changes. At that time we would start sending back and forth
* empty messages, unless we can provide results.
*/
virtual void finishItemChanges() {}
engine: change tracking optional for caching mode and item modification Recording the revision of items during a caching sync is unnecessary because the next sync will not use the information. For item modifications, the information was not even recorded. Now a "don't need changes" mode can be set in SyncSource, which is done for caching and command line item operations. This is better than second-guessing the mode in which a source is used. SyncSourceRevision checks that flag and skips updating the luid->revision mapping if set. Individual backends can also check the flag and skip calculating the revision to begin with.
2013-06-11 15:25:37 +02:00
/**
* In some usage scenarios, change tracking is not necessary.
* This includes local caching (where local data is not expected
* to changed outside of sync) or item manipulation.
*
* The user of a source must explicitly disable change tracking,
* see SyncSource.
*/
virtual bool needChanges() { return true; }
read-ahead: tell SyncSource about the upcoming read accesses Trying to predict in the SyncSource which items will be needed is hard. It depends what the item is retrieved for (sync or backup/printing) and on the sync mode (during a sync). Instead of guessing, better have the user of the source tell the source in advance what it will read. In most cases this is cheap because it does not involve copying of items luids ("read all items", "read new or modified items"). The source then can use its own internal mechanisms to figure out what that means. Only extracting specific items specified on the command line and the backup operation must explicitly pass an ordered list of luids. For the sake of simplicity, do that in a std::vector even though it involves copying.
2013-06-28 08:58:18 +02:00
enum ReadAheadOrder {
READ_ALL_ITEMS, /** all items as reported by the ReadNextItem operation */
READ_CHANGED_ITEMS, /** read updated or added items as reported by the ReadNextItem operation */
READ_SELECTED_ITEMS, /** read items as given in an explicit list */
READ_NONE /** remove previous hint */
};
typedef std::vector<std::string> ReadAheadItems;
/**
* Provides a hint to the source which items are going to be read
* next. A source may use this to implement read-ahead. This
* is just a hint, the source must also work if reads turn out to
* ask for other items.
*/
virtual void setReadAheadOrder(ReadAheadOrder order,
const ReadAheadItems &luids = ReadAheadItems())
{ }
virtual void getReadAheadOrder(ReadAheadOrder &order,
ReadAheadItems &luids)
{
order = READ_NONE;
luids.clear();
}
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
protected:
struct SynthesisInfo {
/**
* name to use for MAKE/PARSETEXTWITHPROFILE,
* leave empty when acessing the field list directly
*/
std::string m_profile;
/**
* the second parameter for MAKE/PARSETEXTWITHPROFILE
* which specifies a remote rule to be applied when
* converting to and from the backend
*/
std::string m_backendRule;
/** list of supported datatypes in "<use .../>" format */
std::string m_datatypes;
/** native datatype (see getNativeDatatypeName()) */
std::string m_native;
/** name of the field list used by the datatypes */
std::string m_fieldlist;
/**
* One or more Synthesis script statements, separated
* and terminated with a semicolon. Can be left empty.
*
* If not empty, then these statements are executed directly
* before converting the current item fields into
* a single string with MAKETEXTWITHPROFILE() in the sync source's
* <beforewritescript> (see SyncSourceBase::getDatastoreXML()).
*
* This value is currently only used by sync sources which
* set m_profile.
*/
std::string m_beforeWriteScript;
/**
* Same as m_beforeWriteScript, but used directly after
* converting a string into fields with PARSETEXTWITHPROFILE()
* in <afterreadscript>.
*/
std::string m_afterReadScript;
Synthesis engine: allow arbitrary <datastore> config properties SyncSources are now allowed to insert arbitrary config properties into the <datastore></datastore> config. The main motivation is that some backends need to enable <updateallfields>.
2011-06-20 14:10:50 +02:00
/**
* Arbitrary configuration options, can override the ones above
* because they are added to the <datastore></datastore>
* XML configuration directly before the closing element.
*
* One example is adding <updateallfields>: this is necessary
* in backends which depend on getting complete items (= for example,
backends: merge with incoming data by default All backends except for EDS replaced local data wholesale with an incoming update, even if that update came from a peer which did not store all properties. The EDS backend had already been configured earlier to always merge remote and local data before writing it back. Instead of updating each backend individually it makes more sense to make the more intelligent (and more expensive) merging the default in backends derived from SyncSourceSerialize/TrackingSyncSource. Backends which do not want it can remove "<updateallfields>true</updateallfields>" from SynthesisInfo::m_datastoreOptions.
2012-06-15 09:57:23 +02:00
* vCard 3.0 strings) from the engine. Note that any source
* derived from SyncSourceSerialize (= the majority of the backends)
* have this set by default.
Synthesis engine: allow arbitrary <datastore> config properties SyncSources are now allowed to insert arbitrary config properties into the <datastore></datastore> config. The main motivation is that some backends need to enable <updateallfields>.
2011-06-20 14:10:50 +02:00
*/
std::string m_datastoreOptions;
engine: allow StartDataRead/beginSync to start early and late, as needed (BMC #22881) The unconditional change of calling StartDataRead (aka beginSync) early enough so that ActiveSync can force a slow sync had negative consequences, because now it was called before the peer was contacted and credentials were accepted: - broke the "sync started successfully" logic, resulting in notifications for syncs which were supposed to be retried silently (showed up in TestSessionAPIsDummy.testAutoSyncNetworkFailure) - database dumps were done even if not needed because sync never starts Now all backends are called as before unless they explicitly ask for the early call. The ActiveSync backend does that. The downsides of that approach do not matter much because syncing will start okay and dumping of data is typically disable on that side of a local sync.
2011-10-20 15:18:48 +02:00
/**
* If true, then the StartDataRead call (aka SyncSourceSession::beginSync)
* is invoked before the first message exchange with the peer. Otherwise
* it is invoked only if the peer could be reached and accepts the credentials.
*
* See SyncSourceSession::beginSync for further comments.
*/
Bool m_earlyStartDataRead;
SyncSource: grant control over "read-only" mode The Synthesis engine already supports read-only datastores. All writes for such a store are silently discarded. Now a SyncSource can select that mode by setting SynthesisInfo::m_readOnly to true in its getSynthesisInfo() implementation.
2012-02-03 09:54:59 +01:00
/**
* If true, then the storage is considered read-only by the
* engine. All write requests by the peer will be silently
* discarded. This is necessary for slow syncs, where the peer
* might send back modified items.
*/
Bool m_readOnly;
local + remote sync: negotiate UID support via SyncCap (BMC #22783) This uses the new libsynthesis support for adding and checking entries in the SyncCap to detect per datastore whether UID/RECURRENCE-ID are truly globally unique and thus can be used to finding pairs. The presence of the property alone is no guarantee for that. Previously this kind of pairing was enabled only for local sync, which was a hack which didn't work for local backends which didn't support UID (for example, Maemo 5 calendar). It also didn't work for mixtures of datastores with and without that kind of support. "1122583000" was randomly chosen as pseudo sync mode. It is a number because strings confuse Funambol. Note that SYNCMODESUPPORTED() only works inside the compare script.
2012-04-26 14:27:22 +02:00
/**
* If true, then the storage preserves and supports UID and
* (in iCalendar 2.0) RECURRENCE-ID with the "globally unique"
* semantic from iCalendar 2.0 (id assigned once when item is
* created). If both sides in a sync support this, then the
* engine can rely on these properties to find matching items
* during a slow sync.
testing: fixed testInsertTwice Backends need to declare how they'll react to inserting the same item (= same UID) item twice.
2012-07-10 09:29:34 +02:00
*
* Matches ClientTestConfig::m_sourceKnowsItemSemantic.
local + remote sync: negotiate UID support via SyncCap (BMC #22783) This uses the new libsynthesis support for adding and checking entries in the SyncCap to detect per datastore whether UID/RECURRENCE-ID are truly globally unique and thus can be used to finding pairs. The presence of the property alone is no guarantee for that. Previously this kind of pairing was enabled only for local sync, which was a hack which didn't work for local backends which didn't support UID (for example, Maemo 5 calendar). It also didn't work for mixtures of datastores with and without that kind of support. "1122583000" was randomly chosen as pseudo sync mode. It is a number because strings confuse Funambol. Note that SYNCMODESUPPORTED() only works inside the compare script.
2012-04-26 14:27:22 +02:00
*/
Bool m_globalIDs;
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
};
/**
* helper function for getDatastoreXML(): fill in information
* as necessary
*
* @retval fragments the necessary definitions for the other
* return values have to be added here
*/
virtual void getSynthesisInfo(SynthesisInfo &info,
XMLConfigFragments &fragments) = 0;
/**
* utility code: creates Synthesis <use datatype=...>
* statements, using the predefined vCard21/vCard30/vcalendar10/icalendar20
* types. Throws an error if no suitable result can be returned (empty or invalid type)
*
* @param type the format specifier as used in SyncEvolution configs, with and without version
* (text/x-vcard:2.1, text/x-vcard, text/x-vcalendar, text/calendar, text/plain, ...);
* see SourceType::m_format
* @param forceFormat if true, then don't allow alternative formats (like vCard 3.0 in addition to 2.1);
* see SourceType::m_force
* @return generated XML fragment
*/
std::string getDataTypeSupport(const std::string &type,
bool forceFormat);
};
/**
* SyncEvolution accesses all sources through this interface.
*
* Certain functionality is optional or can be implemented in
* different ways. These methods are accessed through functors
* (function objects) which may be unset. The expected usage is that
* derived classes fill in the pieces that they provide by binding the
* functors to normal methods. For example, TrackingSyncSource
* provides a normal base class with pure virtual functions which have
* to be provided by users of that class.
*
* Error reporting is done via the Log class.
*/
class SyncSource : virtual public SyncSourceBase, public SyncSourceConfig, public SyncSourceReport
{
public:
SyncSource(const SyncSourceParams &params);
virtual ~SyncSource() {}
SyncSource: remove special RegisterSyncSource::InactiveSource pointer The special semantic of the former RegisterSyncSource::InactiveSource (invalid pointer of value 1) caused bugs, like using it in --print-databases (=> segfault) or not being able to store the result of a createSource() directly in a smart pointer (=> potential leak in SyncSource::createSource()). Obviously a bad idea to start with. Replaced with a RegisterSyncSource::InactiveSource() method which creates a real, inactive SyncSource instance which can and must be deleted by the caller. This is a SyncSource API change for backend developers. Instead of RegisterSyncSource::InactiveSource, return RegisterSyncSource::InactiveSource(). Comparisons against RegisterSyncSource::InactiveSource needs to be replaced with a call to the new SyncSource::isInactive(). User visible fixes: * --print-databases: no longer crashes when EDS or KDE backends are not usable. Instead it prints "not enabled during compilation or not usable in the current environment". * --print-databases: continues with other backends even if one backend throws an exception, as the KDE backend does when it cannot find Akonadi. Error messages are printed.
2012-03-08 11:15:22 +01:00
/** true in sources which are not meant to be used, see RegisterSyncSource::InactiveSource() */
virtual bool isInactive() const { return false; }
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
/**
* SyncSource implementations must register themselves here via
* RegisterSyncSource
*/
static SourceRegistry &getSourceRegistry();
/**
* SyncSource tests are registered here by the constructor of
* RegisterSyncSourceTest
*/
static TestRegistry &getTestRegistry();
struct Database {
SyncSource: allow marking databases as read-only This is relevant for WebDAV database scanning (read-only databases should not be the default) and could also be used to enhance automatic setups (for example, do not use two-way syncing for read-only databases).
2014-04-23 11:13:58 +02:00
Database(const string &name, const string &uri, bool isDefault = false, bool isReadOnly = false) :
m_name( name ), m_uri( uri ), m_isDefault(isDefault), m_isReadOnly(isReadOnly) {}
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
string m_name;
string m_uri;
bool m_isDefault;
SyncSource: allow marking databases as read-only This is relevant for WebDAV database scanning (read-only databases should not be the default) and could also be used to enhance automatic setups (for example, do not use two-way syncing for read-only databases).
2014-04-23 11:13:58 +02:00
bool m_isReadOnly;
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
};
typedef vector<Database> Databases;
/**
* returns a list of all know data sources for the kind of items
* supported by this sync source
*/
virtual Databases getDatabases() = 0;
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
/**
* Creates a new database.
* The default implementation just throws an error.
*
* @param database At least the name should be set. Some backends
* may also be able to create the database with
* a specific URI.
* @return description of the new database
*/
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
virtual Database createDatabase(const Database &database) { throwError(SE_HERE, "creating databases is not supported by backend " + getBackend()); return Database("", ""); }
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
/**
* Removing a database primarily removes the meta data about the
* database. The data itself may still exist in a trash folder.
* The enum tells the deleteDatabase() call what the intention of
* the caller is.
*/
enum RemoveData {
REMOVE_DATA_DEFAULT, /**< do whatever makes most sense for the backend */
REMOVE_DATA_FORCE, /**< force immediate purging of the data, fail if not possible */
REMOVE_DATA_KEEP /**< keep data, only remove access to it */
};
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
/**
* Removes a database. To map a "database" property to a uri,
* instantiate the source with the desired config, open() it and
* then call getDatabase().
*
PIM: allow removal of data together with database removal (part of FDO #64835) There is a difference in EDS between removing the database definition from the ESourceRegistry (which makes the data unaccessible via EDS) and removing the actual database. EDS itself only removes the definition and leaves the data around to be garbage-collected eventually. This is not what we want for the PIM Manager API; the API makes a stronger guarantee that data is really gone. Fixed by introducing a new mode flag for the deleteDatabase() method and deleting the directory of the source directly in the EDS backend, if requested by the caller. The syncevolution command line tool will use the default mode and thus keep the data around, while the PIM Manager forces the removal of data.
2013-05-24 09:42:13 +02:00
* @param uri unique identifier for the database
* @param removeData describes what to do about the database content
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
*/
code restructing: Exception, throwError() Raising exceptions via throwError() looses the original source code location information. Fixing that by explicitly passing that information as additional parameter, created with the preprocessor macro SE_HERE. Several files included the complex SyncContext.h only because needed throwError(). A better place for the revised implementation is the Exception class which used to be in util.h, now Exception.h. Simplifying the include statements exposed indirect include dependencies and removed "using namespace std" from the compilation of some source files which happened to rely on it. We want to get rid of that name space polution, so fix the code instead of adding it back.
2014-04-02 14:57:56 +02:00
virtual void deleteDatabase(const std::string &uri, RemoveData removeData) { throwError(SE_HERE, "deleting databases is not supported by backend " + getBackend()); }
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
/**
* Actually opens the data source specified in the constructor,
* will throw the normal exceptions if that fails. Should
* not modify the state of the sync source.
*
* The expectation is that this call is fairly light-weight, but
* does enough checking to determine whether the source is
* usable. More expensive operations (like determining changes)
* should be done in the m_startDataRead callback (bound to
* beginSync() in some of the utility classes).
*
* In clients, it will be called for all sources before
* the sync starts. In servers, it is called for each source once
* the client asks for it, but not sooner.
*/
virtual void open() = 0;
command line: revise usability checking of datastores When configuring a new sync config, the command line checks whether a datastore is usable before enabling it. If no datastores were listed explicitly, only the usable ones get enabled. If unusable datastores were explicitly listed, the entire configure operation fails. This check was based on listing databases, which turned out to be too unspecific for the WebDAV backend: when "database" was set to some URL which is good enough to list databases, but not a database URL itself, the sources where configured with that bad URL. Now a new SyncSource::isUsable() operation is used, which by default just falls back to calling the existing Operations::m_isEmpty. In practice, all sources either check their config in open() or the m_isEmpty operation, so the source is usable if no error is enountered. For WebDAV, the usability check is skipped because it would require contacting a remote server, which is both confusing (why does a local configure operation need the server?) and could fail even for valid configs (server temporarily down). The check was incomplete anyway because listing databases gave a fixed help text response when no credentials were given. For usability checking that should have resulted in "not usable" and didn't. The output during the check was confusing: it always said "listing databases" without giving a reason why that was done. The intention was to give some feedback while a potentially expensive operation ran. Now the isUsable() method itself prints "checking usability" if (and only if!) such a check is really done. Sometimes datastores were checked even when they were about to be configure as "disabled" already. Now checking such datastores is skipped.
2014-08-20 15:16:12 +02:00
/**
* Checks whether the source as currently configured can access
* data. open() must have been called first.
*
* The default implementation calls Operations::m_isEmpty; this
* assumes that m_isEmpty really does something with the
* database. Derived classes which neither check their config in
* open() nor during m_isEmpty() should provide their own
* implementation of isUsable(). It might also be possible to
* check usability more efficiently.
*
* It is also possible to suppress the usability check by
* providing an implementation which always returns true, for
* example when checking would be too expensive or lead to
* unexpected operations (like accessing a remote server).
*
* If unusable, the implementation should print an INFO message
* explaining why the source is unusable. Whether that is an
* error will be determined by the caller.
*
* @return false if the source is definitely unusable, true if it
* is usable or might be
*/
virtual bool isUsable();
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
/**
* Returns the actual database that is in use. open() must
* have been called first.
*
* Useful because the "database" property might be empty or
* be interpreted in different ways by different backends.
*
* Needed for deleting databases. Not implemented in all
* backends. The default implementation returns an empty
* structure.
*
* @return Database structure with at least m_uri set if
* the actual database is known.
*/
Database getDatabase() const { return m_database; }
/**
* To be called by derived implementation of open().
*/
void setDatabase(const Database &database) { m_database = database; }
SyncSource: moved read-only access to operations into SyncSourceBase This change is necessary for MapSyncSource, which needs to access the operations via its SubSyncSource pointer, which is derived from SyncSourceBase instead of SyncSource (to avoid double inheritance of members). Together with getOperations(), the definition also had to be moved, which is such a big change that "diff" shows the change as "moving code around Operations" instead of "moving Operations".
2010-10-25 10:06:52 +02:00
/**
* Read-only access to operations. Derived classes can modify
* them via m_operations.
*/
SyncSource: rewrote callback handling for operations A few operations had a callback registration mechanism, but not all. For testing multi-cycle syncing and injecting concurrent changes while a sync runs it is necessary to add code for several more operations (begin data read, add/modify/delete item). Instead of adding more custom code, this commit replaces the home-grown callback lists with a boost::function wrapper which contains pre- and post-signals based on boost::signals2. Also simplifies the Synthesis DB Plugin implementation by moving the common code (null check, exception handling) into the wrapper. This removed the LOCERR_OK return code from some plugin implementations (end data read, start data write). Implementations returning LOCERR_OK must be provided by the SyncSource. Done by SyncSourceSession (used by TrackingSyncSource) automatically.
2012-02-13 10:33:24 +01:00
virtual const Operations &getOperations() const { return m_operations; }
SyncSource::Operations: added callback for starting to use source The new m_startAccess is called before the source's m_startDataRead and thus marks the point where a source is used for the first time during a sync. This is necessary for initializing sources in a server on demand. Because this happens inside SyncContext, at least callbacks must be possible for outside classes. Setting the other operations is still limited to derived classes.
2010-02-10 17:43:02 +01:00
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* closes the data source so that it can be reopened
*
* Just as open() it should not affect the state of
* the database unless some previous action requires
* it.
*/
virtual void close() = 0;
PBAP: Suspend/ResumeSync() (FDO #72112) The information that the sync is freezing is now also handed down to the transport and all sources. In the case of PBAP caching, the local transport notifies the child where the PBAP source then uses Bluez 5.15 Transfer1.Suspend/Resume to freeze/thaw the actual OBEX transfer. If that fails (for example, not implemented because Bluez is too old or the transfer is still queueing), then the transfer gets cancelled and the entire sync fails. This is desirable for PBAP caching and Bluetooth because a failed sync can easily be recovered from (just start it again) and the overall goal is to free up Bluetooth bandwidth quickly.
2014-03-07 08:15:37 +01:00
/**
* A hint to the source that syncing will stop processing data
* for a while (freeze = true) or resume processing (freeze =
* false).
*
* If the source needs to change its own state to accomodate
* the new freeze state of the sync and that change fails, then
* the source must throw an error in setFreeze(). The caller will
* not interact with the source while frozen and thus would not
* notice the failure if no error was thrown.
*/
virtual void setFreeze(bool freeze) {}
PIM: enhanced progress notifications (FDO #72114) This adds GetPeerStatus() and "progress" events. To detect DB changes as they happen, the SyncSource operations are monitored. Upon entry, a counter gets increased and transmitted through to the PIM manager in syncevo-dbus-server using extended SourceProgress structs (only visible internally - public API must not be extended!). This will count operations which fail and count those twice which get resumed, so the counts will be too high occasionally. That is in line with the API definition; because it is not exact, the API only exposes a "modified" flag. Progress is reported based on the "item received" Synthesis event and the total item count. A modified libsynthesis is needed where the SyncML binfile client on the target side of the local sync actually sends the total item count (via NumberOfChanges). This cannot be done yet right at the start of the sync, only the second SyncML message will have it. That is acceptable, because completion is reached very quickly anyway for syncs involving only one message. At the moment, SyncContext::displaySourceProgress() holds back "item received" events until a different event needs to be emitted. Progress reporting might get more fine-grained when adding allowing held back events to be emitted at a fixed rate, every 0.1s. This is not done yet because it seems to work well enough already. For testing and demonstration purposes, sync.py gets command line arguments for setting progress frequency and showing progress either via listening to signals or polling.
2014-01-30 21:02:10 +01:00
/**
* Number of InsertItem operations, regardless whether the
* operation succeeded or failed. Operations which get suspended
* are counted again each time they are resumed.
*/
int32_t getAdded() const { return m_added; }
int32_t getUpdated() const { return m_updated; }
int32_t getDeleted() const { return m_deleted; }
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* return Synthesis API pointer, if one currently is available
* (between SyncEvolution_Module_CreateContext() and
* SyncEvolution_Module_DeleteContext())
*/
Synthesis API: move utility code to read/write keys into SDKInterface The new SDKInterface wraps the underlying SDK_Interface pointer in a slightly nicer, more C++ friendly API (methods instead of function pointers, dynamic allocation of buffer).
2009-08-13 17:22:45 +02:00
virtual SDKInterface *getSynthesisAPI() const;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* change the Synthesis API that is used by the source
*/
Synthesis API: move utility code to read/write keys into SDKInterface The new SDKInterface wraps the underlying SDK_Interface pointer in a slightly nicer, more C++ friendly API (methods instead of function pointers, dynamic allocation of buffer).
2009-08-13 17:22:45 +02:00
void pushSynthesisAPI(sysync::SDK_InterfaceType *synthesisAPI);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* remove latest Synthesis API and return to previous one (if any)
*/
Synthesis API: move utility code to read/write keys into SDKInterface The new SDKInterface wraps the underlying SDK_Interface pointer in a slightly nicer, more C++ friendly API (methods instead of function pointers, dynamic allocation of buffer).
2009-08-13 17:22:45 +02:00
void popSynthesisAPI();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SyncSource + SyncContext: added requestAnotherSync() The long term goal is that using a specific sync source once more in another, new sync session can be requested per source. The actual implementation however is per-session, using the new libsynthesis "restartsync" session variable. This functionality sits in SyncContext, because it is the one which has access to the session variables.
2012-02-03 17:47:51 +01:00
/**
* If called while a sync session runs (i.e. after m_startDataRead
* (aka beginSync()) and before m_endDataWrite (aka endSync())),
* the engine will finish the session and then immediately try to
* run another session where any source in which requestAnotherSync()
* was called is active again. There is no guarantee that this
* will be possible.
*
* The source must be prepared to correctly handle another sync
* session. m_endDataWrite will be called and then the sequence
* of calls starts again at m_startDataRead.
*
* The sync mode will switch to an incremental sync in the same
* direction as the initial sync (one-way to client or server,
* two-way).
*
* Does nothing when called at the wrong time. There's no
* guarantee either that restarting is possible.
*
* Currently only supported when a single source is active in
* the initial sync.
*/
void requestAnotherSync();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* factory function for a SyncSource that provides the
* source type specified in the params.m_nodes.m_configNode
*
* @param error throw a runtime error describing what the problem is if no matching source is found
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
* @param config optional, needed for intantiating virtual sources
* @return valid instance, NULL if no source can handle the given type (only when error==false)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
static SyncSource *createSource(const SyncSourceParams &params,
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
bool error = true,
SyncConfig *config = NULL);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Factory function for a SyncSource with the given name
* and handling the kind of data specified by "type" (e.g.
* "Evolution Contacts:text/x-vcard").
*
* The source is instantiated with dummy configuration nodes under
* the pseudo server name "testing". This function is used for
* testing sync sources, not for real syncs. If the prefix is set,
* then <prefix>_<name>_1 is used as database, just as in the
* Client::Sync and Client::Source tests. Otherwise the default
* database is used.
*
* @param error throw a runtime error describing what the problem is if no matching source is found
* @return NULL if no source can handle the given type
*/
static SyncSource *createTestingSource(const string &name, const string &type, bool error,
const char *prefix = getenv("CLIENT_TEST_EVOLUTION_PREFIX"));
libsyncevolution: load backends in function instead of constructor Previously, backends were loaded in a constructor. At some point (*), that loading crashed with a segfault in the dynamic linker. To make debugging a bit easier and rule out non-determinism as the root cause of that crash, loading backends was moved into SyncContect::initMain(). (*) the crash happened when there were two backends which couldn't be loaded due to missing libraries and was related to error strings. A simpler test program did not trigger the problem, and now SyncEvolution has suitable backends for (hopefully?!) all platforms, so it no longer occurs, at least not during automated testing.
2016-09-20 17:11:49 +02:00
/**
* Initialize and/or load backends. No longer
* done automatically to give libsyncevolution
* better control over when backends get loaded.
*/
static void backendsInit();
revised backend API: fixed potential crash after calling SyncSourceBackendDebug/Info() std::iostream.str() created a temporary std::string which was destructed when these functions returned, therefore the c_str() pointer returned by these functions was invalid. Changed the return type so that a dynamically created std::string can be returned. Moved the functions into SyncSource, because conceptually they are related to SyncSource::createSource().
2009-09-27 22:18:24 +02:00
/**
* Some information about available backends.
* Multiple lines, formatted for users of the
* command line.
*/
static string backendsInfo();
/**
* Debug information about backends.
*/
static string backendsDebug();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
Server Alerted Sync: Set Content Type in SAN Nokia phone (S40, 7710c) does not accept the null content type. SyncSource::getPeerMimeType is added for this purpose, each backend implementation can provide a MimeType used for sync by default. For TrackingSyncSource based backend implementations it maps to getMimeType directly.
2009-11-18 07:22:33 +01:00
/**
SyncSource: comments clarified for GetPeerMimeType()
2010-03-18 10:24:04 +01:00
* Mime type a backend communicates with the remote peer by default,
* this is used to alert the remote peer in SAN during server alerted sync.
Server Alerted Sync: Set Content Type in SAN Nokia phone (S40, 7710c) does not accept the null content type. SyncSource::getPeerMimeType is added for this purpose, each backend implementation can provide a MimeType used for sync by default. For TrackingSyncSource based backend implementations it maps to getMimeType directly.
2009-11-18 07:22:33 +01:00
*/
backend API cleanup: removal of "const char *" return types SyncConfig inherited "const char *" from the Funambol C++ API and some other methods used the same approach for efficient access to plain strings. However, this has the disadvantage that dynamically generated strings cannot be returned. SyncConfig had to use an awkward workaround with a local string cache. This patch converts most of that code to a normal std::string return value and removes the string cache. Out-of-tree backends must be adapted, otherwise they won't compile.
2011-01-18 15:07:46 +01:00
virtual std::string getPeerMimeType() const =0;
Server Alerted Sync: Set Content Type in SAN Nokia phone (S40, 7710c) does not accept the null content type. SyncSource::getPeerMimeType is added for this purpose, each backend implementation can provide a MimeType used for sync by default. For TrackingSyncSource based backend implementations it maps to getMimeType directly.
2009-11-18 07:22:33 +01:00
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/* implementation of SyncSourceBase */
backend API cleanup: removal of "const char *" return types SyncConfig inherited "const char *" from the Funambol C++ API and some other methods used the same approach for efficient access to plain strings. However, this has the disadvantage that dynamically generated strings cannot be returned. SyncConfig had to use an awkward workaround with a local string cache. This patch converts most of that code to a normal std::string return value and removes the string cache. Out-of-tree backends must be adapted, otherwise they won't compile.
2011-01-18 15:07:46 +01:00
virtual std::string getName() const { return SyncSourceConfig::getName(); }
Import Upstream version 1.5.3
2021-09-29 23:01:46 +02:00
virtual std::string getDisplayName() const { return m_name; }
testing: improved logging + CLIENT_TEST_SOURCE_DELAY Exceptions reported by CppUnit only contained one file+line pair. If that location was called multiple times inside a larger test, then it was impossible to tell where it was called. The new assertion macros and in particular CT_ASSERT_NO_THROW() solve this problem by catching exceptions, adding the current file+line information and then rethrowing an extended exception. When CppUnit finally logs the problem, it will contain a complete call stack. For this to work, every single line which might throw an exception must be wrapped in a macro. Entering and leaving the line is logged together with the wrapped expression as part of the test .log file. doSync() is handled as a special case and gets the file+line info of its caller via parameters. New logging macros are introduced and used in LocalTests::testChanges: instead of writing comments, call the logging macros and the string will appear also in the .log file of the test. Further areas for improvements: - use CLIENT_TEST_LOG() everywhere - reduce file names to just the base name is logged - convert .log file into HTML with links into session logs and ClientTest.cpp source file
2011-11-07 22:02:04 +01:00
virtual void setDisplayName(const std::string &name) { m_name = name; }
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
virtual long getNumDeleted() const { return m_numDeleted; }
virtual void setNumDeleted(long num) { m_numDeleted = num; }
virtual void incrementNumDeleted() { m_numDeleted++; }
engine: change tracking optional for caching mode and item modification Recording the revision of items during a caching sync is unnecessary because the next sync will not use the information. For item modifications, the information was not even recorded. Now a "don't need changes" mode can be set in SyncSource, which is done for caching and command line item operations. This is better than second-guessing the mode in which a source is used. SyncSourceRevision checks that flag and skips updating the luid->revision mapping if set. Individual backends can also check the flag and skip calculating the revision to begin with.
2013-06-11 15:25:37 +02:00
virtual bool needChanges() { return m_needChanges; }
void setNeedChanges(bool needChanges) { m_needChanges = needChanges; }
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
SAN + forced slow sync: move flag into SyncSource The main motivation for this change was that access to that flag was needed inside the SyncSource while experimenting with slow sync detection. In the end, the flag was not really needed there. Applying this patch might make sense anyway, just in case that a similar need arises again. Eventually it might also allow to remove the entire SourceConfigSpecials structure.
2010-01-29 19:40:44 +01:00
/**
* Set to true in SyncContext::initSAN() when a SyncML server has
* to force a client into slow sync mode. This is necessary because
* the server cannot request that mode (missing in the standard).
* Forcing the slow sync mode is done via a FORCESLOWSYNC() macro
* call in an <alertscript>.
*/
void setForceSlowSync(bool forceSlowSync) { m_forceSlowSync = forceSlowSync; }
bool getForceSlowSync() const { return m_forceSlowSync; }
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
protected:
Operations m_operations;
private:
/**
* Counter for items deleted in the source. Has to be incremented
* by RemoveAllItems() and DeleteItem(). This counter is used to
* update the Synthesis engine counter in those cases where the
* engine does not (refresh from server) or cannot
* (RemoveAllItems()) count the removals itself.
*/
long m_numDeleted;
PIM: enhanced progress notifications (FDO #72114) This adds GetPeerStatus() and "progress" events. To detect DB changes as they happen, the SyncSource operations are monitored. Upon entry, a counter gets increased and transmitted through to the PIM manager in syncevo-dbus-server using extended SourceProgress structs (only visible internally - public API must not be extended!). This will count operations which fail and count those twice which get resumed, so the counts will be too high occasionally. That is in line with the API definition; because it is not exact, the API only exposes a "modified" flag. Progress is reported based on the "item received" Synthesis event and the total item count. A modified libsynthesis is needed where the SyncML binfile client on the target side of the local sync actually sends the total item count (via NumberOfChanges). This cannot be done yet right at the start of the sync, only the second SyncML message will have it. That is acceptable, because completion is reached very quickly anyway for syncs involving only one message. At the moment, SyncContext::displaySourceProgress() holds back "item received" events until a different event needs to be emitted. Progress reporting might get more fine-grained when adding allowing held back events to be emitted at a fixed rate, every 0.1s. This is not done yet because it seems to work well enough already. For testing and demonstration purposes, sync.py gets command line arguments for setting progress frequency and showing progress either via listening to signals or polling.
2014-01-30 21:02:10 +01:00
/**
* Counter for InsertItem operations. Updated by hooking into the operation.
*/
int32_t m_added, m_updated, m_deleted;
SAN + forced slow sync: move flag into SyncSource The main motivation for this change was that access to that flag was needed inside the SyncSource while experimenting with slow sync detection. In the end, the flag was not really needed there. Applying this patch might make sense anyway, just in case that a similar need arises again. Eventually it might also allow to remove the entire SourceConfigSpecials structure.
2010-01-29 19:40:44 +01:00
bool m_forceSlowSync;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Interface pointer for this sync source, allocated for us by the
* Synthesis engine and registered here by
* SyncEvolution_Module_CreateContext(). Only valid until
* SyncEvolution_Module_DeleteContext(), in other words, while
* the engine is running.
*/
std::vector<sysync::SDK_InterfaceType *> m_synthesisAPI;
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
SyncSource: add API for creating and deleting databases The API supports creating a database with a specific name and UID. To avoid ambiguities, deleting is done via the UID. Looking up the UID for a "database" property value is meant to be supported by opening the SyncSource and then getting the current database that was opened. This allows implementing a delete operation that uses the same database lookup method as syncing. All of the new methods have stubs which reject the operation respectively tell the caller that no information is available. This was done to avoid having to adapt all derived SyncSources. Support for the new functionality is optional.
2012-09-13 17:50:57 +02:00
/** database in use after open(), to be set via setDatabase() by derived class */
Database m_database;
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
/** actual name of the source */
std::string m_name;
engine: change tracking optional for caching mode and item modification Recording the revision of items during a caching sync is unnecessary because the next sync will not use the information. For item modifications, the information was not even recorded. Now a "don't need changes" mode can be set in SyncSource, which is done for caching and command line item operations. This is better than second-guessing the mode in which a source is used. SyncSourceRevision checks that flag and skips updating the luid->revision mapping if set. Individual backends can also check the flag and skip calculating the revision to begin with.
2013-06-11 15:25:37 +02:00
/** change tracking enabled? */
bool m_needChanges;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
sync progress: generate information about inactive sources Sources which aren't active during a sync exist in the SyncEvolution and therefore GUIs may show them. The Synthesis engine isn't told about these sources, so it won't generate any events for them. This patch generates the normal 100% done events and the final source is "done" events inside the EvolutionSyncClient before even invoking the Synthesis engine. That way GUIs don't have to treat these inactive sources in any special way. The command line output is aware of this change and suppresses output for inactive sources, except for a single INFO line which tells the user that the source is inactive. Because of the way the internal API works, it is necessary to instantiate a dummy SyncSource with no config nodes.
2009-09-23 14:48:38 +02:00
/**
* A SyncSource with no pure virtual functions.
*/
class DummySyncSource : public SyncSource
{
public:
DummySyncSource(const SyncSourceParams &params) :
SyncSource(params) {}
local sync: disambiguate source names During local sync names like "addressbook" are no longer unique, because they may exist in both the local and the remote context. This patch introduces a "display name" composed from context and source name, like this: "@<context>/<source>" (@default/addressbook). The context is only used if needed, which currently is the case during a local sync. Changing the SyncSourceBase::getName() result was also considered, but several places expect this to be the name of the source inside its context, so an explicit SyncSourceBase::getDisplayName() turned out to be safer.
2010-10-22 14:02:01 +02:00
DummySyncSource(const std::string &name, const std::string &contextName) :
SyncSource config: grant sources read/write access to context The intention always was that backends may add their own properties. For sync properties this seemed less relevant, so sources only got read access to it. But the WebDAV backends run with their own "source-config" context and now need read/write access to store information that is shared between all sources. Therefore this patch removes the "const" qualifier from SyncConfig.
2011-04-15 13:26:55 +02:00
SyncSource(SyncSourceParams(name, SyncSourceNodes(), boost::shared_ptr<SyncConfig>(), contextName)) {}
sync progress: generate information about inactive sources Sources which aren't active during a sync exist in the SyncEvolution and therefore GUIs may show them. The Synthesis engine isn't told about these sources, so it won't generate any events for them. This patch generates the normal 100% done events and the final source is "done" events inside the EvolutionSyncClient before even invoking the Synthesis engine. That way GUIs don't have to treat these inactive sources in any special way. The command line output is aware of this change and suppresses output for inactive sources, except for a single INFO line which tells the user that the source is inactive. Because of the way the internal API works, it is necessary to instantiate a dummy SyncSource with no config nodes.
2009-09-23 14:48:38 +02:00
virtual Databases getDatabases() { return Databases(); }
virtual void open() {}
virtual void close() {}
virtual void getSynthesisInfo(SynthesisInfo &info,
XMLConfigFragments &fragments) {}
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
virtual void enableServerMode() {}
virtual bool serverModeEnabled() const { return false; }
backend API cleanup: removal of "const char *" return types SyncConfig inherited "const char *" from the Funambol C++ API and some other methods used the same approach for efficient access to plain strings. However, this has the disadvantage that dynamically generated strings cannot be returned. SyncConfig had to use an awkward workaround with a local string cache. This patch converts most of that code to a normal std::string return value and removes the string cache. Out-of-tree backends must be adapted, otherwise they won't compile.
2011-01-18 15:07:46 +01:00
virtual std::string getPeerMimeType() const {return "";}
sync progress: generate information about inactive sources Sources which aren't active during a sync exist in the SyncEvolution and therefore GUIs may show them. The Synthesis engine isn't told about these sources, so it won't generate any events for them. This patch generates the normal 100% done events and the final source is "done" events inside the EvolutionSyncClient before even invoking the Synthesis engine. That way GUIs don't have to treat these inactive sources in any special way. The command line output is aware of this change and suppresses output for inactive sources, except for a single INFO line which tells the user that the source is inactive. Because of the way the internal API works, it is necessary to instantiate a dummy SyncSource with no config nodes.
2009-09-23 14:48:38 +02:00
};
Join/dejoin Mutiple SyncSources, MB#4611 As Nokia phone stores calendar and todos in one datastore, we need to utilize synthesis superdatastore to handle this case. A virtual SyncSource is introduced which has a backend type "virtual" and its local database path points to a list of sub syncsources. The virtual syncsource is maintained by SyncSourceList and used to generate appropriate synthesis superdatastore configuraitons. unescapeJoinedString is introduced to parse a comma seperated list of sub syncsources. At this time, the configuration is fixed to work with "calendar+todo" case.
2009-11-23 02:43:56 +01:00
/**
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
* A special source which combines one or more real sources.
* Most of the special handling for that is in SyncContext.cpp.
*
* This class can be instantiated, opened and closed if and only if
* the underlying sources also support that.
Join/dejoin Mutiple SyncSources, MB#4611 As Nokia phone stores calendar and todos in one datastore, we need to utilize synthesis superdatastore to handle this case. A virtual SyncSource is introduced which has a backend type "virtual" and its local database path points to a list of sub syncsources. The virtual syncsource is maintained by SyncSourceList and used to generate appropriate synthesis superdatastore configuraitons. unescapeJoinedString is introduced to parse a comma seperated list of sub syncsources. At this time, the configuration is fixed to work with "calendar+todo" case.
2009-11-23 02:43:56 +01:00
*/
class VirtualSyncSource : public DummySyncSource
{
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
std::vector< boost::shared_ptr<SyncSource> > m_sources;
VirtualSyncSource, MapSyncSource: implement m_isEmpty This is relevant for isUsable() and not so much (not at all?) for slow sync prevention.
2014-08-20 16:23:15 +02:00
bool isEmpty();
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
Join/dejoin Mutiple SyncSources, MB#4611 As Nokia phone stores calendar and todos in one datastore, we need to utilize synthesis superdatastore to handle this case. A virtual SyncSource is introduced which has a backend type "virtual" and its local database path points to a list of sub syncsources. The virtual syncsource is maintained by SyncSourceList and used to generate appropriate synthesis superdatastore configuraitons. unescapeJoinedString is introduced to parse a comma seperated list of sub syncsources. At this time, the configuration is fixed to work with "calendar+todo" case.
2009-11-23 02:43:56 +01:00
public:
virtual source: support D-Bus CheckSource() (MB #9535) As Jussi found out, the CheckSource() D-Bus method always declared a virtual source as "unusable". The underlying reason was that instantiating a SyncSource corresponding to a virtual source config was not possible. If that had worked, it wouldn't have checked the underlying sources. This patch fixes both problems by extending VirtualSyncSource (now instantiates and opens underlying sources) and SyncSource::createSource() (now recognizes "virtual" and creates a VirtualSyncSource). Because creating proper sources depends on the SyncConfig, this must be passed as parameter into createSource/VirtualSyncSource when that kind of checking is desired. Besides opening the underlying sources, VirtualSyncSource::open() also verifies that it has a proper data format. I noticed that this code had been copied from SyncSourceSerialize. I moved the common code into a new SyncSourceBase::getDataTypeSupport(). Error checking also was a bit streamlined. For example, bad or missing MIME type are detected in SyncSourceBase::getDataTypeSupport(), which allows us to remove the corresponding check in SyncContext.cpp. Note that SyncSource::throwError() should be used for source-specific problems instead of SE_THROW(), because it includes the name of the source in the exception.
2010-02-08 15:04:59 +01:00
/**
* @param config optional: when given, the constructor will instantiate the
* referenced underlying sources and check them in open()
*/
VirtualSyncSource(const SyncSourceParams &params, SyncConfig *config = NULL);
/** opens underlying sources and checks config by calling getDataTypeSupport() */
virtual void open();
virtual void close();
/**
* returns array with source names that are referenced by this
* virtual source
*/
std::vector<std::string> getMappedSources();
/**
* returns <use datatype=...> statements for XML config,
* throws error if not configured correctly
*/
std::string getDataTypeSupport();
using SyncSourceBase::getDataTypeSupport;
VirtualSyncSource: implement getDatabases() This is required when creating the configuration with virtual sources, otherwise a virtual SyncSource will always be marked as 'disabled' because it thought there is "no database to synchronize".
2010-03-17 10:03:59 +01:00
/*
* If any of the sub datasource has no databases associated, return an empty
* database list to indicate a possibly error condition; otherwise return a
* dummy database to identify "calendar+todo" combined datasource.
**/
virtual Databases getDatabases();
Join/dejoin Mutiple SyncSources, MB#4611 As Nokia phone stores calendar and todos in one datastore, we need to utilize synthesis superdatastore to handle this case. A virtual SyncSource is introduced which has a backend type "virtual" and its local database path points to a list of sub syncsources. The virtual syncsource is maintained by SyncSourceList and used to generate appropriate synthesis superdatastore configuraitons. unescapeJoinedString is introduced to parse a comma seperated list of sub syncsources. At this time, the configuration is fixed to work with "calendar+todo" case.
2009-11-23 02:43:56 +01:00
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Hooks up the Synthesis DB Interface start sync (BeginDataRead) and
* end sync (EndDataWrite) calls with virtual methods. Ensures that
* sleepSinceModification() is called.
*
* Inherit from this class in your sync source and call the init()
* method to use it.
*/
class SyncSourceSession : virtual public SyncSourceBase {
public:
/**
* called before Synthesis engine starts to ask for changes and item data
*
engine: allow StartDataRead/beginSync to start early and late, as needed (BMC #22881) The unconditional change of calling StartDataRead (aka beginSync) early enough so that ActiveSync can force a slow sync had negative consequences, because now it was called before the peer was contacted and credentials were accepted: - broke the "sync started successfully" logic, resulting in notifications for syncs which were supposed to be retried silently (showed up in TestSessionAPIsDummy.testAutoSyncNetworkFailure) - database dumps were done even if not needed because sync never starts Now all backends are called as before unless they explicitly ask for the early call. The ActiveSync backend does that. The downsides of that approach do not matter much because syncing will start okay and dumping of data is typically disable on that side of a local sync.
2011-10-20 15:18:48 +02:00
* If SynthesisInfo::m_earlyStartDataRead is true, then this call is
* invoked before the first message exchange with a peer and it
* may throw a STATUS_SLOW_SYNC_508 StatusException if an
SyncSource: allow StartDataRead/beginSync() to force a slow sync This is needed for ActiveSync, which can detect inside beginSync() that the sync key became invalid and then has to fall back to a slow sync. It is done by asking the engine to call StartDataRead earlier (via <plugin_earlystartdataread>) and documenting the special 508 error code. Depends on support for both in libsynthesis, thus the bumped version number of it. Normally SyncEvolution is meant to never throw an exception unless something fatal happens, so it would have been better to add a return code to beginSync(). But that is a fairly intrusive change, so instead the simpler "use exception" solution is used. The change can still be made later on.
2011-10-12 09:49:32 +02:00
* incremental sync is not possible. In that case, preparations
* for a slow sync must have completed successfully inside the
* beginSync() call. It is not going to get called again.
*
engine: allow StartDataRead/beginSync to start early and late, as needed (BMC #22881) The unconditional change of calling StartDataRead (aka beginSync) early enough so that ActiveSync can force a slow sync had negative consequences, because now it was called before the peer was contacted and credentials were accepted: - broke the "sync started successfully" logic, resulting in notifications for syncs which were supposed to be retried silently (showed up in TestSessionAPIsDummy.testAutoSyncNetworkFailure) - database dumps were done even if not needed because sync never starts Now all backends are called as before unless they explicitly ask for the early call. The ActiveSync backend does that. The downsides of that approach do not matter much because syncing will start okay and dumping of data is typically disable on that side of a local sync.
2011-10-20 15:18:48 +02:00
* If SynthesisInfo::m_earlyStartDataRead is false (the default),
* then this is called only if the peer was reachable and accepted
* the credentials. This mode of operation is preferred if a fallback
* to slow sync is not needed, because it allows deferring expensive
* operations until really needed. For example, the engine does
* database dumps at the time when StartDataRead is called.
*
SyncSource: allow StartDataRead/beginSync() to force a slow sync This is needed for ActiveSync, which can detect inside beginSync() that the sync key became invalid and then has to fall back to a slow sync. It is done by asking the engine to call StartDataRead earlier (via <plugin_earlystartdataread>) and documenting the special 508 error code. Depends on support for both in libsynthesis, thus the bumped version number of it. Normally SyncEvolution is meant to never throw an exception unless something fatal happens, so it would have been better to add a return code to beginSync(). But that is a fairly intrusive change, so instead the simpler "use exception" solution is used. The change can still be made later on.
2011-10-12 09:49:32 +02:00
* See StartDataRead for details.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*
* @param lastToken identifies the last completed sync
* @param resumeToken identifies a more recent sync which needs to be resumed;
* if not empty, then report changes made after that sync
* instead of the last completed sync
*/
virtual void beginSync(const std::string &lastToken, const std::string &resumeToken) = 0;
/**
* called after completing or suspending the current sync
*
* See EndDataWrite for details.
*
* @return a token identifying this sync session for a future beginSync()
*/
virtual std::string endSync(bool success) = 0;
/** set Synthesis DB Interface operations */
void init(SyncSource::Operations &ops);
private:
sysync::TSyError startDataRead(const char *lastToken, const char *resumeToken);
sysync::TSyError endDataWrite(bool success, char **newToken);
};
/**
* Implements the Synthesis DB Interface for reporting item changes
* (ReadNextItemAsKey) *without* actually delivering the item data.
*/
class SyncSourceChanges : virtual public SyncSourceBase {
public:
SyncSourceChanges();
enum State {
ANY,
NEW,
UPDATED,
DELETED,
MAX
};
/**
* Add the LUID of a NEW/UPDATED/DELETED item.
* If unspecified, the luid is added to the list of
* all items. This must be done *in addition* to adding
* the luid with a specific state.
*
* For example, the luid of an updated item should be added with
* addItem(luid [, ANY]) and again with addItem(luid, DELETED).
*
* The Synthesis engine does not need the list of deleted items
* and does not distinguish between added and updated items, so
* for syncing, adding DELETED items is optional and all items
* which are different from the last sync can be added as
CalDAV + MapSyncSource: rewrote change tracking Trying to reuse the TrackingSyncSource change tracking was a dead-end that just led to horribly complex scaffolding classes (like the key/value node which had to keep revisions synchronized and mix in UID). This is a complete rewrite where change detection is done in MapSyncSource, using a similar approach as in TrackingSyncSource. Some of the session life cycle is now cut-and-pasted from TrackingSyncSource (primarily checking the overall database revision). Eventually this common logic might get refactored into a SyncSource utility class, but for now let's keep it separate. This solution is much cleaner and uses simpler key/value storage with one item-<mainid> entry for each merged item, mapping to the revision, UID, and list of subids.
2011-06-28 19:28:15 +02:00
* UPDATED. The client-test program expects that the informationb
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
* is provided precisely.
*
* @return true if the luid was already listed
*/
bool addItem(const string &luid, State state = ANY);
SyncSource: support multiple sync cycles in the same session The state of SyncSourceChanges and SyncSourceRevisions must be reset in beginSync() to get change tracking right when the same session includes more than the traditional single sync cycle. SyncSourceRevisions::initRevisions() must clear its set of revisions before filling the data structure again. Otherwise items removed as part of a sync are not detected as deleted in the next cycle. Any backend derived using these classes (like any backend derived from TrackingSyncSource) should work now and all other backends should be fixed to support multiple cycles, so the <canrestart> flag is set unconditionally. Still need Client::Source tests for this expected behavior.
2012-02-07 16:43:04 +01:00
/**
* Wipe out all added items, returning true if any were found.
*/
bool reset();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
typedef std::set<std::string> Items_t;
const Items_t &getItems(State state) { return m_items[state]; }
const Items_t &getAllItems() const { return m_items[ANY]; }
const Items_t &getNewItems() const { return m_items[NEW]; }
const Items_t &getUpdatedItems() const { return m_items[UPDATED]; }
const Items_t &getDeletedItems() const { return m_items[DELETED]; }
/** set Synthesis DB Interface operations */
void init(SyncSource::Operations &ops);
private:
Items_t m_items[MAX];
bool m_first;
Items_t::const_iterator m_it;
sysync::TSyError iterate(sysync::ItemID aID,
sysync::sInt32 *aStatus,
bool aFirst);
};
/**
* Implements the Synthesis DB Interface for deleting an item
* (DeleteItem). Increments number of deleted items in
* SyncSourceBase.
*/
class SyncSourceDelete : virtual public SyncSourceBase {
public:
virtual void deleteItem(const string &luid) = 0;
/** set Synthesis DB Interface operations */
void init(SyncSource::Operations &ops);
private:
sysync::TSyError deleteItemSynthesis(sysync::cItemID aID);
};
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
enum InsertItemResultState {
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
/**
* Operation not complete, invoke callback in ItemResult to check
* for progress.
*/
ITEM_AGAIN,
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
/**
* item added or updated as requested
*/
ITEM_OKAY,
/**
* When a backend is asked to add an item and recognizes
* that the item matches an already existing item, it may
* replace that item instead of creating a duplicate. In this
* case it must return ITEM_REPLACED and set the luid/revision
* of that updated item.
*
* This can happen when such an item was added concurrently to
* the running sync or, more likely, was reported as new by
* the backend and the engine failed to find the match because
* it doesn't know about some special semantic, like iCalendar
* 2.0 UID).
*
* Note that depending on the age of the items, the older data
* will replace the more recent one when always using item
* replacement.
*/
ITEM_REPLACED,
/**
* Same as ITEM_REPLACED, except that the backend did some
* modifications to the data that was sent to it before
* storing it, like merging it with the existing item. The
* engine will treat the updated item as modified and send
* back the update to the peer as soon as possible. In server
* mode that will be in the same sync session, in a client in
* the next session (client cannot send changes after having
* received data from the server).
*/
ITEM_MERGED,
/**
* As before, a match against an existing item was detected.
* By returning this state and the luid of the matched item
* (revision not needed) the engine is instructed to do the
* necessary data comparison and merging itself. Useful when a
* backend can't do the necessary merging itself.
*/
ITEM_NEEDS_MERGE
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* an interface for reading and writing items in the internal
* format; see SyncSourceSerialize for an explanation
*/
class SyncSourceRaw : virtual public SyncSourceBase {
public:
class InsertItemResult {
public:
InsertItemResult() :
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
m_state(ITEM_OKAY)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
{}
/**
* @param luid the LUID after the operation; during an update the LUID must
* not be changed, so return the original one here
* @param revision the revision string after the operation; leave empty if not used
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
* @param state report about what was done with the data
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
InsertItemResult(const string &luid,
const string &revision,
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
InsertItemResultState state) :
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
m_luid(luid),
m_revision(revision),
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
m_state(state)
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
{}
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
/**
* Constructor for the case where the final result is not available yet.
*
* @param check will be called again later to poll for completion
*/
InsertItemResult(const boost::function<InsertItemResult ()> &check) :
m_state(ITEM_AGAIN),
m_continue(check)
{}
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
string m_luid;
string m_revision;
SyncSource API: support and use Synthesis DB_DataMerged/Replace/Conflict result codes (BMC #22783) Returning 207 = DB_DataMerged when an item replaced an existing one wasn't correct (the data wasn't really merged) and also wasn't handled as intended by the Synthesis engine. Now a backend can properly report what it did: - data fully replaced - data was merged - data needs to be merged by engine The last option is used by EDS and CalDAV when an add<->add conflict is detected by the backends. In that case the Synthesis engine will read the local item, merge it with the incoming item and write back the result. At the moment the tests assume that the more recent item wins completely. But our field list config specifies a merge=lines mode for some fields, which results in concatenating these fields in the merged item. Thus the tests currently fail. Need to decide which behavior is desired.
2011-09-13 10:58:49 +02:00
InsertItemResultState m_state;
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
typedef ContinueOperation<InsertItemResult ()> Continue_t;
Continue_t m_continue;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
/** same as SyncSourceSerialize::insertItem(), but with internal format */
virtual InsertItemResult insertItemRaw(const std::string &luid, const std::string &item) = 0;
/** same as SyncSourceSerialize::readItem(), but with internal format */
virtual void readItemRaw(const std::string &luid, std::string &item) = 0;
};
/**
* Implements the Synthesis DB Interface for importing/exporting item
* data (ReadItemAsKey, InsertItemAsKey, UpdateItemAsKey) in such a
* way that the sync source only has to deal with a text
* representation of an item.
*
* There may be two such representations:
* - "engine format" is the one exchanged with the Synthesis engine
* - "internal or raw format" is a format that might better capture
* the internal representation and can be used for backup/restore
* and testing
*
* To give an example, the EvolutionMemoSource uses plain text as
* engine format and iCalendar 2.0 as raw format.
*
* The BackupData_t and RestoreData_t operations are implemented by
* this class using the internal format.
*
* The engine format must be something that the Synthesis engine can
* parse and generate, in other words, there must be a corresponding
* profile in the XML configuration. This class uses information
* provided by the sync source (mime type and version) and from the
* configuration (format selected by user) to generate the required
* XML configuration parts for common configurations (vCard,
* vCalendar, iCalendar, text). Special representations can be added
* to the global XML configuration by overriding default
* implementations provided in this class.
*
* InsertItemAsKey and UpdateItemAsKey are mapped to the same
* insertItem() call because in practice it can happen that a request
* to add an item must be turned into an update. For example, a
* meeting was imported both into the server and the client. A request
* to add the item again should be treated as an update, based on the
* unique iCalendar 2.0 LUID.
*/
class SyncSourceSerialize : virtual public SyncSourceBase, virtual public SyncSourceRaw {
public:
/**
* Returns the preferred mime type of the items handled by the sync source.
* Example: "text/x-vcard"
*/
backend API cleanup: removal of "const char *" return types SyncConfig inherited "const char *" from the Funambol C++ API and some other methods used the same approach for efficient access to plain strings. However, this has the disadvantage that dynamically generated strings cannot be returned. SyncConfig had to use an awkward workaround with a local string cache. This patch converts most of that code to a normal std::string return value and removes the string cache. Out-of-tree backends must be adapted, otherwise they won't compile.
2011-01-18 15:07:46 +01:00
virtual std::string getMimeType() const = 0;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Returns the version of the mime type used by client.
* Example: "2.1"
*/
backend API cleanup: removal of "const char *" return types SyncConfig inherited "const char *" from the Funambol C++ API and some other methods used the same approach for efficient access to plain strings. However, this has the disadvantage that dynamically generated strings cannot be returned. SyncConfig had to use an awkward workaround with a local string cache. This patch converts most of that code to a normal std::string return value and removes the string cache. Out-of-tree backends must be adapted, otherwise they won't compile.
2011-01-18 15:07:46 +01:00
virtual std::string getMimeVersion() const = 0;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* returns the backend selection and configuration
*/
InitState: merged InitState and InitStateClass The new InitState template works for both classes and generic types. The difference is in the kind of base class that it inherits from: the one for classes "is" an instance of the wrapped type, the other "has" such an instance. boost::is_class is used to pick the right utility class, something that had to be done manually previously. While touching the classes, the explicit initialization with "const char *" was replace with a more general template constructor. The main advantage is that other template code, like the D-Bus traits, no longer needs to distinguish between InitState and InitStateClass. The InitState implementation did not become smaller. At least it avoids code duplication (m_wasSet handled in one place).
2012-09-13 16:59:24 +02:00
virtual InitState<SourceType> getSourceType() const = 0;
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Create or modify an item.
*
* The sync source should be flexible: if the LUID is non-empty, it
* shall modify the item referenced by the LUID. If the LUID is
* empty, the normal operation is to add it. But if the item
* already exists (e.g., a calendar event which was imported
* by the user manually), then the existing item should be
* updated also in the second case.
*
* Passing a LUID of an item which does not exist is an error.
* This error should be reported instead of covering it up by
* (re)creating the item.
*
* Errors are signaled by throwing an exception. Returning empty
* strings in the result is an error which triggers an "item could
* not be stored" error.
*
* @param luid identifies the item to be modified, empty for creating
* @param item contains the new content of the item, using the engine format
* @return the result of inserting the item
*/
virtual InsertItemResult insertItem(const std::string &luid, const std::string &item) = 0;
/**
* Return item data in engine format.
*
* @param luid identifies the item
* @retval item item data
*/
virtual void readItem(const std::string &luid, std::string &item) = 0;
/* implement SyncSourceRaw under the assumption that the internal and engine format are identical */
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
virtual InsertItemResult insertItemRaw(const std::string &luid, const std::string &item);
virtual void readItemRaw(const std::string &luid, std::string &item);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/** set Synthesis DB Interface operations */
void init(SyncSource::Operations &ops);
protected:
/**
* used getMimeType(), getMimeVersion() and getSourceType()
* to provide the information necessary for automatic
* conversion to the sync source's internal item representation
*/
XML configuration: always add mapping, using correct fieldlist name The <fieldmap> is necessary to have access to individual fields. Previously, only the "itemdata" variable was available to backends. Now all fields can be read and written under their field names (<automap>). Because this only works if the correct fieldlist name is given, this information now has to be provided as part of getSynthesisInfo(). Replaced list of strings with struct to allow future source-code compatible API changes, like adding another field. Of course, this will only work as long as the new fields are optional.
2009-08-13 17:36:12 +02:00
virtual void getSynthesisInfo(SynthesisInfo &info,
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
XMLConfigFragments &fragments);
private:
sysync::TSyError readItemAsKey(sysync::cItemID aID, sysync::KeyH aItemKey);
SyncSource: support asynchronous add/update in utility classes SyncSourceSerialize uses ITEM_AGAIN plus a callback in InsertItemResult to indicate that and how an insert (aka add or update) operation must be continued. TrackingSyncSource merely passes that result through until it finally completes. Direct, raw access to items as done by the command line and restore operations is not done asynchronously. The backend does not need to know how it is used, the SyncSourceSerialize wrapper around the backend will flush and wait. Asynchronous deleting is not supported. It would require throwing an exception or an API change (better - exceptions are for errors!) because removeItem() has no return code which could be extended.
2013-06-07 11:48:45 +02:00
SyncSource::Operations::InsertItemAsKeyResult_t insertItemAsKey(sysync::KeyH aItemKey, sysync::ItemID newID);
SyncSource::Operations::UpdateItemAsKeyResult_t updateItemAsKey(sysync::KeyH aItemKey, sysync::cItemID aID, sysync::ItemID newID);
sysync::TSyError insertContinue(sysync::ItemID newID, const InsertItemResult::Continue_t &cont);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
SyncSource: refactored backup utility code Made ItemCache available as part of SyncSource.h and moved the "add item to cache" code from SyncSourceRevisions into ItemCache::backupItem(). The code turned out to be useful when implementing backup in a backend which couldn't quite use SyncSourceRevisions directly.
2010-10-25 10:11:08 +02:00
/**
* Mapping from Hash() value to file.
* Used by SyncSourceRevisions, but may be of use for
* other backup implementations.
*/
class ItemCache
{
public:
#ifdef USE_SHA256
typedef std::string Hash_t;
Hash_t hashFunc(const std::string &data) { return SHA_256(data); }
#else
typedef unsigned long Hash_t;
Hash_t hashFunc(const std::string &data) { return Hash(data); }
#endif
typedef unsigned long Counter_t;
/** mark the algorithm used for the hash via different suffices */
static const char *m_hashSuffix;
/**
* Collect information about stored hashes. Provides
* access to file name via hash.
*
* If no hashes were written (as in an old SyncEvoltion
* version), we could read the files to recreate the
* hashes. This is not done because it won't occur
* often enough.
*
* Hashes are also not verified. Users should better
* not edit them or file contents...
*
* @param oldBackup existing backup to read; may be empty
* @param newBackup new backup to be created
* @param legacy legacy mode includes a bug
* which cannot be fixed without breaking on-disk format
*/
void init(const SyncSource::Operations::ConstBackupInfo &oldBackup,
const SyncSource::Operations::BackupInfo &newBackup,
bool legacy);
/**
* create file name for a specific hash, empty if no such hash
*/
string getFilename(Hash_t hash);
/**
* add a new item, reusing old one if possible
*
* @param item new item data
* @param uid its unique ID
* @param rev revision string
*/
void backupItem(const std::string &item,
const std::string &uid,
const std::string &rev);
/** to be called after init() and all backupItem() calls */
void finalize(BackupReport &report);
ItemCache: allow backup dumps to restart Added ItemCache::reset(), will be used by WebDAV backend if dumping data fails in the middle and needs to be retried.
2011-04-15 14:24:30 +02:00
/** can be used to restart creating the backup after an intermediate failure */
void reset();
SyncSource: refactored backup utility code Made ItemCache available as part of SyncSource.h and moved the "add item to cache" code from SyncSourceRevisions into ItemCache::backupItem(). The code turned out to be useful when implementing backup in a backend which couldn't quite use SyncSourceRevisions directly.
2010-10-25 10:11:08 +02:00
private:
typedef std::map<Hash_t, Counter_t> Map_t;
Map_t m_hash2counter;
string m_dirname;
SyncSource::Operations::BackupInfo m_backup;
bool m_legacy;
unsigned long m_counter;
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Implements change tracking based on a "revision" string, a string
* which is guaranteed to change automatically each time an item is
* modified. Backup/restore is optionally implemented by this class if
* pointers to SyncSourceRaw and SyncSourceDelete interfaces are
* passed to init(). For backup only the former is needed, for restore
* both.
*
* Potential implementations of the revision string are:
* - a modification time stamp
* - a hash value of a textual representation of the item
* (beware, such a hash might change as the textual representation
* changes even though the item is unchanged)
*
* Sync sources which want to use this functionality have to provide
* the following functionality by implementing the pure virtual
* functions below:
* - enumerate all existing items
* - provide LUID and the revision string
* The LUID must remain *constant* when making changes to an item,
* whereas the revision string must *change* each time the item is
* changed by anyone.
* Both can be arbitrary strings, but keeping them simple (printable
* ASCII, no white spaces, no equal sign) makes debugging simpler
* because they can be stored as they are as key/value pairs in the
* sync source's change tracking config node (the .other.ini files when
* using file-based configuration). More complex strings use escape
* sequences introduced with an exclamation mark for unsafe characters.
*
* Most of the functionality of this class must be activated
* explicitly as part of the life cycle of the sync source instance by
* calling detectChanges(), updateRevision() and deleteRevision().
*
* If the required interfaces are provided to init(), then backup/restore
* operations are set. init() also hooks into the session life cycle
* with an end callback that ensures that enough time passes at the end
* of the sync. This is important for sync sources which use time stamps
* as revision string. "enough time" is defined by a parameter to the
* init call.
*/
class SyncSourceRevisions : virtual public SyncSourceChanges, virtual public SyncSourceBase {
public:
typedef map<string, string> RevisionMap_t;
/**
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
* Fills the complete mapping from UID to revision string of all
* currently existing items.
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*
* Usually both UID and revision string must be non-empty. The
* only exception is a refresh-from-client: in that case the
* revision string may be empty. The implementor of this call
* cannot know whether empty strings are allowed, therefore it
* should not throw errors when it cannot create a non-empty
* string. The caller of this method will detect situations where
* a non-empty string is necessary and none was provided.
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
*
sources: force slow sync when listAllItems() returns no revisions First, clarified that a source has to set all revision strings or none. This was implied, but not spelled out explicitly. Second, use that to detect when a sync must be done in slow mode. Third, avoid calculating changes when that isn't needed. This last point was left as TODO while in release preparations and can be committed now. This changes is needed for the PBAP backend which does not currently set revision strings and thus cannot be used in incremental syncing.
2012-08-31 15:00:25 +02:00
* An source must set the revision string for all items or
* none at all.
*
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
* This call is typically only invoked only once during the
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
* lifetime of a source, at the time when detectChanges() needs
* the information. The result returned in that invocation is
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
* used throught the session.
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
*
* When detectChanges() is called with CHANGES_NONE, listAllItems()
* is avoided. Instead the cached information is used. Sources
* may need to know that information, so in this case setAllItems()
* is called as part of detectChanges().
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
virtual void listAllItems(RevisionMap_t &revisions) = 0;
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
/**
* Called by SyncSourceRevisions::detectChanges() to tell
* the derived class about the cached information if (and only
SyncSourceRevisions: added updateAll[Sub]Items There may be backends (like CalDAV) where updating existing information about items is more efficient than reading them from scratch. This commit adds updateAll[Sub]Items in SyncSourceRevisions/TrackingSyncSource resp. the SubSyncSource API for that purpose. If it is called when some information exits (without it, the attempt would be useless) and when change tracking may resuse existing information. So an explicit slow sync still reads all items and wipes out all old information, just in case that it is somehow broken. Should not matter in most cases, though, because wrong luids and mismatching revisions will be detected and corrected. The only situation where incorrect information would matter is correct luid+revision with wrong meta information attached in MapSyncSource (subids, UID, ...).
2011-06-25 12:19:13 +02:00
* if) listAllItems() and updateAllItems() were not called. The derived class
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
* might not need this information, so the default implementation
* simply ignores.
*
* A more complex API could have been defined to only prepare the
* information when needed, but that seemed unnecessarily complex.
*/
virtual void setAllItems(const RevisionMap_t &revisions) {}
SyncSourceRevisions: added updateAll[Sub]Items There may be backends (like CalDAV) where updating existing information about items is more efficient than reading them from scratch. This commit adds updateAll[Sub]Items in SyncSourceRevisions/TrackingSyncSource resp. the SubSyncSource API for that purpose. If it is called when some information exits (without it, the attempt would be useless) and when change tracking may resuse existing information. So an explicit slow sync still reads all items and wipes out all old information, just in case that it is somehow broken. Should not matter in most cases, though, because wrong luids and mismatching revisions will be detected and corrected. The only situation where incorrect information would matter is correct luid+revision with wrong meta information attached in MapSyncSource (subids, UID, ...).
2011-06-25 12:19:13 +02:00
/**
* updates the revision map to reflect the current state
*
* May be called instead of listAllItems() if the caller has
* a valid list to start from. If the implementor
* cannot update the list, it must start from scratch by
* reseting the list and calling listAllItems(). The default
* implementation of this method does that.
*/
virtual void updateAllItems(SyncSourceRevisions::RevisionMap_t &revisions) {
revisions.clear();
listAllItems(revisions);
}
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
/**
* Tells detectChanges() how to do its job.
*/
enum ChangeMode {
/**
* Call listAllItems() and use the list of previous items
* to calculate changes.
*/
CHANGES_FULL,
/**
* Don't rely on previous information. Will call
* listAllItems() and generate a full list of items based on
* the result.
*/
CHANGES_SLOW,
/**
* Caller has already determined that a) no items have changed
* and that b) the list of previous items is valid. For example,
* some backends have a way of getting a revision string for
* the whole database and can compare that against the value
* from the end of the previous sync.
*
* In this mode, listAllItems() doesn't have to be called.
* A list of all items will be created, with no items marked
* as added/updated/deleted.
*/
CHANGES_NONE
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* calculate changes, call when sync source is ready for
* listAllItems() and before changes are needed
*
* The trackingNode must be provided by the caller. It will
* be updated by each of the calls and must be stored by
* the caller.
*
* @param trackingNode a config node for exclusive use by this class
sync sources: added support for avoiding listAllItems() If a sync source can quickly determine that nothing has changed, then SyncSourceRevisions::detectChanges() can use a shortcut and simply copy the list of known uids => CHANGES_NONE mode. Such a change detection will be possible in the WebDAV backends (using the Calendar Collection Entity Tag (CTag) as "database revision" string) and perhaps in the future also in Evolution Data Server (after adding a new API). This commit also adds a CHANGES_SLOW mode. This is meant as hint that detecting changes is not necessary. Right now, this mode is the same as CHANGES_FULL because the code changes should be minimized at this time (in preparation for 1.2). More work will probably be needed to distinguish between unit testing and real real slow syncs. Finally, a way to pass information about the cached item list is added with the SyncSourceRevision::setAllItems() call. setAllItems() and listAllItems() are mutually exclusive: either the backend delivers the information, or it receives it. The CalDAV backend depends on this because it needs to maintain a cache with information about all items.
2011-06-22 11:53:53 +02:00
* @param mode determines how changes are detected; if unsure,
* use CHANGES_FULL, which will always produce
* the required information, albeit more slowly
* than the other modes
sources: force slow sync when listAllItems() returns no revisions First, clarified that a source has to set all revision strings or none. This was implied, but not spelled out explicitly. Second, use that to detect when a sync must be done in slow mode. Third, avoid calculating changes when that isn't needed. This last point was left as TODO while in release preparations and can be committed now. This changes is needed for the PBAP backend which does not currently set revision strings and thus cannot be used in incremental syncing.
2012-08-31 15:00:25 +02:00
* @return true if change detection could only provide a list of currently
* existing items, but not the list of added/updated/deleted items
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
*/
sources: force slow sync when listAllItems() returns no revisions First, clarified that a source has to set all revision strings or none. This was implied, but not spelled out explicitly. Second, use that to detect when a sync must be done in slow mode. Third, avoid calculating changes when that isn't needed. This last point was left as TODO while in release preparations and can be committed now. This changes is needed for the PBAP backend which does not currently set revision strings and thus cannot be used in incremental syncing.
2012-08-31 15:00:25 +02:00
bool detectChanges(ConfigNode &trackingNode, ChangeMode mode);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* record that an item was added or updated
*
* @param old_luid empty for add, old LUID otherwise
* @param new_luid normally LUIDs must not change, but this call allows it
* @param revision revision string after change
*/
void updateRevision(ConfigNode &trackingNode,
const std::string &old_luid,
const std::string &new_luid,
const std::string &revision);
/**
* record that we deleted an item
*
* @param luid the obsolete LUID
*/
void deleteRevision(ConfigNode &trackingNode,
const std::string &luid);
/**
* set Synthesis DB Interface and backup/restore operations
* @param raw needed for backups; if NULL, no backups are made
* @param del needed for restores; if NULL, only backups are possible
* @param granularity time that has to pass between making a modification
* and checking for changes; this class ensures that
* at least this amount of time has passed before letting
* the session terminate. Delays in different source do
* not add up.
*/
void init(SyncSourceRaw *raw, SyncSourceDelete *del,
int granularity,
SyncSource::Operations &ops);
private:
SyncSourceRaw *m_raw;
SyncSourceDelete *m_del;
int m_revisionAccuracySeconds;
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
/** buffers the result of the initial listAllItems() call */
RevisionMap_t m_revisions;
bool m_revisionsSet;
SyncSource: support multiple sync cycles in the same session The state of SyncSourceChanges and SyncSourceRevisions must be reset in beginSync() to get change tracking right when the same session includes more than the traditional single sync cycle. SyncSourceRevisions::initRevisions() must clear its set of revisions before filling the data structure again. Otherwise items removed as part of a sync are not detected as deleted in the next cycle. Any backend derived using these classes (like any backend derived from TrackingSyncSource) should work now and all other backends should be fixed to support multiple cycles, so the <canrestart> flag is set unconditionally. Still need Client::Source tests for this expected behavior.
2012-02-07 16:43:04 +01:00
bool m_firstCycle;
SyncSourceRevisions: cache result of listAllItems() (MB #7708) When automatic backups are enabled (the default), SyncSourceRevisions and derived classes like TrackingSyncSource called listAllItems() twice, once during backup and once while checking for changes. This patch introduces caching of the result returned by the first call. During a normal session, that will be during backup, with change detection reusing the information. If backups are off, the call will happen during change detection, as before. Sharing of the listAllItems() result with change tracking only works for the backup that is created at the start of a sync. This piece of information is passed to the backend as part of the BackupInfo structure. The advantages of this change are: - more efficient, in particular for sources where listAllItems() is slow - avoids a race condition (backup stores one set of items, changes are made, change detection works with another set) That race condition is both fairly theoretical (short time window) and had no impact on the correctness of the sync, only on the output (data comparison would not show all changes synced later). Now the race condition still exists if changes are made while a sync runs, which is the bigger problem that still needs to be solved (for EDS, see MB #3479). Restoring data also calls listAllItems(). It does not use the cached information, just in case that it is to be called more than once per instance, and because there is no benefit.
2010-02-16 17:43:41 +01:00
void initRevisions();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Dump all data from source unmodified into the given directory.
* The ConfigNode can be used to store meta information needed for
* restoring that state. Both directory and node are empty.
*/
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
void backupData(const SyncSource::Operations::ConstBackupInfo &oldBackup,
const SyncSource::Operations::BackupInfo &newBackup,
BackupReport &report);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Restore database from data stored in backupData(). Will be
* called inside open()/close() pair. beginSync() is *not* called.
*/
SyncSource API: access to previous backup (MB #7708) This is the API change which will allow a SyncSource implemenation to reuse data and files from a previous backup. Right now, neither the caller nor the callee actually use this option.
2010-02-05 17:57:03 +01:00
void restoreData(const SyncSource::Operations::ConstBackupInfo &oldBackup,
bool dryrun,
SyncSourceReport &report);
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* Increments the time stamp of the latest database modification,
* called automatically whenever revisions change.
*/
void databaseModified();
/** time stamp of latest database modification, for sleepSinceModification() */
core, WebDAV: improved support for aborting while sleeping When waiting for resending a failed message, the sleeping couldn't be interrupted when using the D-Bus server. It now uses the SuspendFlags infrastructure and glib, which detects abort requests sent via D-Bus in addition to those sent via signals (which already worked earlier).
2012-06-20 12:26:12 +02:00
Timespec m_modTimeStamp;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
SyncMLStatus sleepSinceModification();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
SyncSourceLogging: common utility code for logging item changes This class wraps the Synthesis DB methods which update/insert/delete items and logs INFO messages about these changes. These messages contain a short description of the item, which is generated by reading fields (update/insert) or by asking the backend (delete).
2009-08-13 17:43:40 +02:00
/**
* Common logging for sync sources.
*
* This class wraps the Synthesis DB functors that were set before
* calling its init() method. The wrappers then log a single line
* describing what is happening (adding/updating/removing)
* to which item (with a short item specific description extracted
* from the incoming item data or the backend).
*/
class SyncSourceLogging : public virtual SyncSourceBase
{
public:
/**
* wrap Synthesis DB Interface operations
*
* @param fields list of fields to read in getDescription()
* @param sep separator between non-empty fields
*/
void init(const std::list<std::string> &fields,
const std::string &sep,
SyncSource::Operations &ops);
/**
* Extract short description from Synthesis item data.
* The default implementation reads a list of fields
* as strings and concatenates the non-empty ones
* with a separator.
*
* @param aItemKey key for reading fields
* @return description, empty string will cause the ID of the item to be printed
*/
virtual std::string getDescription(sysync::KeyH aItemKey);
/**
* Extract short description from backend.
* Necessary for deleted items. The default implementation
* returns an empty string, so that implementing this
* is optional.
*
* @param luid LUID of the item to be deleted in the backend
* @return description, empty string will cause the ID of the item to be printed
*/
virtual std::string getDescription(const string &luid);
private:
std::list<std::string> m_fields;
std::string m_sep;
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
SyncMLStatus insertItemAsKey(sysync::KeyH aItemKey, sysync::ItemID newID);
SyncMLStatus updateItemAsKey(sysync::KeyH aItemKey, sysync::cItemID aID, sysync::ItemID newID);
SyncMLStatus deleteItem(sysync::cItemID aID);
SyncSourceLogging: common utility code for logging item changes This class wraps the Synthesis DB methods which update/insert/delete items and logs INFO messages about these changes. These messages contain a short description of the item, which is generated by reading fields (update/insert) or by asking the backend (delete).
2009-08-13 17:43:40 +02:00
};
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
/**
* Implements Load/SaveAdminData and MapItem handling in a SyncML
* server. Uses a single property for the admin data in the "internal"
* node and a complete node for the map items.
*/
class SyncSourceAdmin : public virtual SyncSourceBase
{
boost::shared_ptr<ConfigNode> m_configNode;
std::string m_adminPropertyName;
boost::shared_ptr<ConfigNode> m_mappingNode;
SyncSourceAdmin: do not flush mapping table if never loaded For local test scenarios, it is possible the mapping table is never loaded but flushed during endSession, this will empty the mapping file uncontentionaly.
2009-12-11 10:05:20 +01:00
bool m_mappingLoaded;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
ConfigNode: use map with case-insensitive keys for properties The case of property names does not matter. A map where the key is case-insensitive is thus a better data structure for storing a set of property key/value pairs. Such a type was already used by FilterConfigNode. This patch cleans up the config nodes so that all of them use the new ConfigProps type. The previous typedefs inside ConfigNode and FilterConfigNode are preserved to keep old source code working without changing it. The intention is to use the result of readProperties() directly as parameter for setConfigFilter().
2009-11-21 18:10:18 +01:00
ConfigProps m_mapping;
ConfigProps::const_iterator m_mappingIterator;
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
sysync::TSyError loadAdminData(const char *aLocDB,
const char *aRemDB,
char **adminData);
sysync::TSyError saveAdminData(const char *adminData);
bool readNextMapItem(sysync::MapID mID, bool aFirst);
sysync::TSyError insertMapItem(sysync::cMapID mID);
sysync::TSyError updateMapItem(sysync::cMapID mID);
sysync::TSyError deleteMapItem(sysync::cMapID mID);
SyncSource: add operation signal handler return code This allows signal handlers to affect the operation execution and result without having to throw an exception, which would get logged as error and is not desirable when the operation gets skipped intentionally. Needed for skipping SaveAdminData in the next patch.
2014-08-29 11:24:06 +02:00
SyncMLStatus flush();
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
void resetMap();
void mapid2entry(sysync::cMapID mID, string &key, string &value);
void entry2mapid(const string &key, const string &value, sysync::MapID mID);
public:
/** flexible initialization */
void init(SyncSource::Operations &ops,
const boost::shared_ptr<ConfigNode> &config,
Import Upstream version 1.5.3
2021-09-29 23:01:46 +02:00
const std::string &adminPropertyName,
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
const boost::shared_ptr<ConfigNode> &mapping);
/**
* simpler initialization, using the default placement of data
config: reorganized for shared config layout (MB#7707) This patch introduces code changes for the new layout without actually using it yet. Therefore all existing tests for the older layout still pass. The new meaning of the former "server name" is introduced: - A plain string now refers to a peer configuration (can be client or server). - The @ sign allows selecting a specific context. Different contexts have independent sets of local sources and peer definitions. - An empty peer name selects a view on the configuration which contains no peer-specific properties. Not fully implemented yet. The FileConfigTree is instantiated with a root which is one level high up compare to before this patch (for example, "~/.config/syncevolution" instead of "./config/syncevolution/scheduleworld") and then config files include that dropped level in their relative path name ("scheduleworld/config.ini" instead of "config.ini"). This allows accessing the global properties in "~/.config/syncevolution/config.ini" and will be used to move peers further down the hierarchy ("~/.config/syncevolution/peers/scheduleworld/config.ini"). To keep the output of "--print-servers" consistent, the FileConfigTree gets another parameter which identifies the subset of the larger tree that is referenced by this FileConfigTree instance. One side effect of this change is that FileConfigTree instances are no longer completely separate. Something to keep in mind when instantiating SyncContext multiple times (MB#8006). Code may no longer make assumptions in which config node a property is stored. This is determined by the new getNode() calls based on the property attributes (hidden, sharing). The new layout is represented as a set of config nodes. Older layouts use the same set of nodes with identical instances assigned to them, if they don't really have separate files for each of them. SyncSourceNodes no longer grants direct access to the nodes, to catch code which incorrectly access a specific node directly. For the same reason the name of the nodes changed. Code which needs access to all hidden or all visible properties now does this via a config node returned by getProperties(). Currently this is identical to the underlying nodes. Once the new layout is active, this node will act as a multiplexer which gathers properties from all underlying nodes when reading and picks the right one when writing. The "change ID" parameter for sources has been obsolete for a while and was removed. Reorganized the property registration so that it is a bit easier to see which properties are hidden and which use non-default sharing. The default sharing is "no sharing". Some other code was improved while touching it: - removed useless visibility[] array in favor of a i != 0 check in SyncConfig::copy() - added default parameters to save/checkPassword() methods - some constness definition changes - Property::getProperty() is a virtual call which could only be overloaded in one case because the constness was wrong; now getProperty() always returns the string value and getPropertyValue() some other kind of representation of it, depending on the class. - ConstSyncSourceNodes is based on SyncSourceNodes instead of duplicating it, which simplifies the implementation. The simplified SyncSourceAdmin API changed slightly: instead of passing a pointer to the source's SyncSourceNodes, the default nodes are now found via the SyncSource pointer. For callers this is a bit less work and it is more general.
2009-11-13 14:52:00 +01:00
* inside the SyncSourceConfig base class
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
*/
config: reorganized for shared config layout (MB#7707) This patch introduces code changes for the new layout without actually using it yet. Therefore all existing tests for the older layout still pass. The new meaning of the former "server name" is introduced: - A plain string now refers to a peer configuration (can be client or server). - The @ sign allows selecting a specific context. Different contexts have independent sets of local sources and peer definitions. - An empty peer name selects a view on the configuration which contains no peer-specific properties. Not fully implemented yet. The FileConfigTree is instantiated with a root which is one level high up compare to before this patch (for example, "~/.config/syncevolution" instead of "./config/syncevolution/scheduleworld") and then config files include that dropped level in their relative path name ("scheduleworld/config.ini" instead of "config.ini"). This allows accessing the global properties in "~/.config/syncevolution/config.ini" and will be used to move peers further down the hierarchy ("~/.config/syncevolution/peers/scheduleworld/config.ini"). To keep the output of "--print-servers" consistent, the FileConfigTree gets another parameter which identifies the subset of the larger tree that is referenced by this FileConfigTree instance. One side effect of this change is that FileConfigTree instances are no longer completely separate. Something to keep in mind when instantiating SyncContext multiple times (MB#8006). Code may no longer make assumptions in which config node a property is stored. This is determined by the new getNode() calls based on the property attributes (hidden, sharing). The new layout is represented as a set of config nodes. Older layouts use the same set of nodes with identical instances assigned to them, if they don't really have separate files for each of them. SyncSourceNodes no longer grants direct access to the nodes, to catch code which incorrectly access a specific node directly. For the same reason the name of the nodes changed. Code which needs access to all hidden or all visible properties now does this via a config node returned by getProperties(). Currently this is identical to the underlying nodes. Once the new layout is active, this node will act as a multiplexer which gathers properties from all underlying nodes when reading and picks the right one when writing. The "change ID" parameter for sources has been obsolete for a while and was removed. Reorganized the property registration so that it is a bit easier to see which properties are hidden and which use non-default sharing. The default sharing is "no sharing". Some other code was improved while touching it: - removed useless visibility[] array in favor of a i != 0 check in SyncConfig::copy() - added default parameters to save/checkPassword() methods - some constness definition changes - Property::getProperty() is a virtual call which could only be overloaded in one case because the constness was wrong; now getProperty() always returns the string value and getPropertyValue() some other kind of representation of it, depending on the class. - ConstSyncSourceNodes is based on SyncSourceNodes instead of duplicating it, which simplifies the implementation. The simplified SyncSourceAdmin API changed slightly: instead of passing a pointer to the source's SyncSourceNodes, the default nodes are now found via the SyncSource pointer. For callers this is a bit less work and it is more general.
2009-11-13 14:52:00 +01:00
void init(SyncSource::Operations &ops, SyncSource *source);
SyncML server: handle admin data inside SyncEvolution, use <simpleauthuser/pw> Previously, sync failed because the datastore configuration specified no means of storing the admin data (single chunk of text and local ID/remote ID mapping). This could have been added by configuring the SDK_textdb as <plugin_admin_module>. Instead this patch implements the functionality inside SyncEvolution, using a new ".server.ini" config node for the mapping and an internal "adminData" property for the admin data text chunk. This is more natural because it keeps the data under our control. Authentication is configured via <simpleauthuser/pw>. In contrast to using the SDK_textdb, this allows choosing the username and password. Ultimately this should also be done inside SyncEvolution, to avoid writing the username/password into the XML (unsolved encoding issue) and into log files (privacy issue).
2009-09-29 22:41:06 +02:00
};
SyncSourceLogging: common utility code for logging item changes This class wraps the Synthesis DB methods which update/insert/delete items and logs INFO messages about these changes. These messages contain a short description of the item, which is generated by reading fields (update/insert) or by asking the backend (delete).
2009-08-13 17:43:40 +02:00
enable suspend and saving blobs (MB #2425) Implement blob support. Blobs are stored in the per-peer source directory in a ".cache" sub-directory. We could have relied on the peer name and device name to make file names unique when sharing a common directory. Perhaps that is indeed the better solution: ~/.cache/syncevolution/blobs with logdir specifying the root? Blob support is only needed when running as server. When running as client, the binfile layer provides the necessary implementation. Support for suspend was off by default because <resumesupport> was not set. Adding it, because we should have whatever is needed. <resumeitemsupport> depends on the ability to store blobs. Not sure whether this is relevant on the client side, where these services are provided by the binfile layer.
2010-03-04 17:50:01 +01:00
/**
* Implements Read/Write/DeleteBlob. Blobs are stored inside a
* configurable directory, which has to be unique for the current
* peer.
*/
class SyncSourceBlob : public virtual SyncSourceBase
{
/**
* Only one blob is active at a time.
* This utility class provides the actual implementation.
*/
sysync::TBlob m_blob;
sysync::TSyError readBlob(sysync::cItemID aID, const char *aBlobID,
void **aBlkPtr, size_t *aBlkSize,
size_t *aTotSize,
bool aFirst, bool *aLast) {
build failure (S360): size_t != unsigned int (BMC #13201) SyncEvolution 1.1.1 did not build without this patch on S360, because the source used an integer typedef which turned out to be incompatible with size_t, although it should have the same size. Apparently the compiler distinguishes between "unsigned int" and "unsigned long", even if both have the same size.
2011-02-07 14:01:03 +01:00
// Translate between sysync::memSize and size_t, which
// is different on s390 (or at least the compiler complains...).
SyncML server: fixed invalid memory access in blob handling Some parameters were not initialized before calling the underlying libsynthesis implementation.
2012-05-22 11:16:32 +02:00
sysync::memSize blksize = aBlkSize ? static_cast<sysync::memSize>(*aBlkSize) : 0,
totsize = aTotSize ? static_cast<sysync::memSize>(*aTotSize) : 0;
build failure (S360): size_t != unsigned int (BMC #13201) SyncEvolution 1.1.1 did not build without this patch on S360, because the source used an integer typedef which turned out to be incompatible with size_t, although it should have the same size. Apparently the compiler distinguishes between "unsigned int" and "unsigned long", even if both have the same size.
2011-02-07 14:01:03 +01:00
sysync::TSyError err = m_blob.ReadBlob(aID, aBlobID, aBlkPtr,
SyncSourceBlob: avoid crash in ReadBlob() Klocwork correctly reported that the underlying implementation in libsynthesis must not be called with NULL pointers. Therefore always allow it to set the return values, even if our caller was not interested.
2013-03-19 14:58:46 +01:00
&blksize,
&totsize,
build failure (S360): size_t != unsigned int (BMC #13201) SyncEvolution 1.1.1 did not build without this patch on S360, because the source used an integer typedef which turned out to be incompatible with size_t, although it should have the same size. Apparently the compiler distinguishes between "unsigned int" and "unsigned long", even if both have the same size.
2011-02-07 14:01:03 +01:00
aFirst, aLast);
if (aBlkSize) {
*aBlkSize = blksize;
}
if (aTotSize) {
*aTotSize = totsize;
}
return err;
enable suspend and saving blobs (MB #2425) Implement blob support. Blobs are stored in the per-peer source directory in a ".cache" sub-directory. We could have relied on the peer name and device name to make file names unique when sharing a common directory. Perhaps that is indeed the better solution: ~/.cache/syncevolution/blobs with logdir specifying the root? Blob support is only needed when running as server. When running as client, the binfile layer provides the necessary implementation. Support for suspend was off by default because <resumesupport> was not set. Adding it, because we should have whatever is needed. <resumeitemsupport> depends on the ability to store blobs. Not sure whether this is relevant on the client side, where these services are provided by the binfile layer.
2010-03-04 17:50:01 +01:00
}
sysync::TSyError writeBlob(sysync::cItemID aID, const char *aBlobID,
void *aBlkPtr, size_t aBlkSize,
size_t aTotSize,
bool aFirst, bool aLast) {
mkdir_p(m_blob.getBlobPath());
return m_blob.WriteBlob(aID, aBlobID, aBlkPtr, aBlkSize, aTotSize, aFirst, aLast);
}
sysync::TSyError deleteBlob(sysync::cItemID aID, const char *aBlobID) {
return m_blob.DeleteBlob(aID, aBlobID);
}
sysync::TSyError loadAdminData(sysync::cItemID aID, const char *aBlobID,
void **aBlkPtr, size_t *aBlkSize, size_t *aTotSize,
bool aFirst, bool *aLast);
public:
void init(SyncSource::Operations &ops,
const std::string &dir);
};
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
/**
* This is an interface definition that is expected by the client-test
* program. Part of the reason for this requirement is that the test
* program was originally written for the Funambol SyncSource API.
* The other reason is that the testing is based on importing/exporting
* items in the internal format of the sync source, which has to be
* text based or even MIMEDIR based (for tests involving synccompare).
*/
class TestingSyncSource : public SyncSource,
virtual public SyncSourceSession,
virtual public SyncSourceChanges,
virtual public SyncSourceDelete,
virtual public SyncSourceSerialize {
public:
TestingSyncSource(const SyncSourceParams &params) :
SyncSource(params)
{
SyncSourceSession::init(m_operations);
SyncSourceChanges::init(m_operations);
SyncSourceDelete::init(m_operations);
SyncSourceSerialize::init(m_operations);
}
~TestingSyncSource() {}
InitState: merged InitState and InitStateClass The new InitState template works for both classes and generic types. The difference is in the kind of base class that it inherits from: the one for classes "is" an instance of the wrapped type, the other "has" such an instance. boost::is_class is used to pick the right utility class, something that had to be done manually previously. While touching the classes, the explicit initialization with "const char *" was replace with a more general template constructor. The main advantage is that other template code, like the D-Bus traits, no longer needs to distinguish between InitState and InitStateClass. The InitState implementation did not become smaller. At least it avoids code duplication (m_wasSet handled in one place).
2012-09-13 16:59:24 +02:00
virtual InitState<SourceType> getSourceType() const { return SyncSourceConfig::getSourceType(); }
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
TestingSyncSource+CalDAV: added "delete all" API call During testing, removing all items is done via a special call in TestingSyncSource. It used to be an utility method which fell back to the normal SyncSource API. This patch changes several things - Reversed order in which items are deleted in that utility method, because removing children (= longer IDs) first tends to be supported better by servers (bug in CalDAV server, but still...). - Allow backends to implement their own removeAllItems(). - Implement that in CalDAV + MapSyncSource as removing the merged items directly, instead of using a sequence of PUT+final DELETE. Found while testing with Bedework CalDAV server. Makes testing more robust and efficient.
2011-10-04 09:55:18 +02:00
virtual void removeAllItems();
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
};
introduced "namespace SyncEvo" consistently Added syncevo/declarations.h, which has This is now used for all SyncEvolution source files, except for the GTK UI, which is written in plain C. In the library it helps to avoid name clashes. The reason for using defines instead of spelling out "namespace SyncEvo" is twofold: 1. if that should ever become necessary, it is easier to rename the namespace via configure options by changing the define 2. editors don't indent the whole file content
2009-10-02 17:23:53 +02:00
SE_END_CXX
redesigned SyncSource base class + API The main motivation for this change is that it allows the implementor of a backend to choose the implementations for the different aspects of a datasource (change tracking, item import/export, logging, ...) independently of each other. For example, change tracking via revision strings can now be combined with exchanging data with the Synthesis engine via a single string (the traditional method in SyncEvolution) and with direct access to the Synthesis field list (now possible for the first time). The new backend API is based on the concept of providing implementations for certain functionality via function objects instead of implementing certain virtual methods. The advantage is that implementors can define their own, custom interfaces and mix and match implementations of the different groups of functionality. Logging (see SyncSourceLogging in a later commit) can be done by wrapping some arbitrary other item import/export function objects (decorator design pattern). The class hierarchy is now this: - SyncSourceBase: interface for common utility code, all other classes are derived from it and thus can use that code - SyncSource: base class which implements SyncSourceBase and hooks a datasource into the SyncEvolution core; its "struct Operations" holds the function objects which can be implemented in different ways - TestingSyncSource: combines some of the following classes into an interface that is expected by the client-test program; backends only have to derive from (and implement this) if they want to use the automated testing - TrackingSyncSource: provides the same functionality as before (change tracking via revision strings, item import/export as string) in a single interface; the description of the pure virtual methods are duplicated so that developers can go through this class and find everything they need to know to implement it The following classes contain the code that was previously found in the EvolutionSyncSource base class. Implementors can derive from them and call the init() methods to inherit and activate the functionality: - SyncSourceSession: binds Synthesis session callbacks to virtual methods beginSync(), endSync() - SyncSourceChanges: implements Synthesis item tracking callbacks with set of LUIDs that the user of the class has to fill - SyncSourceDelete: binds Synthesis delete callback to virtual method - SyncSourceRaw: read and write items in the backends format, used for testing and backup/restore - SyncSourceSerialize: exchanges items with Synthesis engine using a string representation of the data; this is how EvolutionSyncSource has traditionally worked, so much of the same virtual methods are now in this class - SyncSourceRevisions: utility class which does change tracking via some kind of "revision" string which changes each time an item is modified; this code was previously in the TrackingSyncSource
2009-08-25 09:27:46 +02:00
#endif // INCL_SYNCSOURCE