diff options
author | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-12-28 13:52:46 +0100 |
---|---|---|
committer | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-12-28 13:52:46 +0100 |
commit | 296a5ac347dbccfff44d2b2a0a378e98b0480cac (patch) | |
tree | 2b27aa44b37752dd568a17ce43389ef10845d42b /docs/resource.md | |
parent | d2654f78a4f7e87b44e296477e4d90646c967670 (diff) | |
download | sink-296a5ac347dbccfff44d2b2a0a378e98b0480cac.tar.gz sink-296a5ac347dbccfff44d2b2a0a378e98b0480cac.zip |
Docs
Diffstat (limited to 'docs/resource.md')
-rw-r--r-- | docs/resource.md | 17 |
1 files changed, 11 insertions, 6 deletions
diff --git a/docs/resource.md b/docs/resource.md index d1b2bbe..aa263e8 100644 --- a/docs/resource.md +++ b/docs/resource.md | |||
@@ -5,12 +5,9 @@ The resource consists of: | |||
5 | * a configuration setting of the filters | 5 | * a configuration setting of the filters |
6 | 6 | ||
7 | # Synchronizer | 7 | # Synchronizer |
8 | * The synchronization can either: | 8 | The synchronizer process is responsible for processing all commands, executing synchronizations with the source, and replaying changes to the source. |
9 | * Generate a full diff directly on top of the db. The diffing process can work against a single revision/snapshot (using transactions). It then generates a necessary changeset for the store. | ||
10 | * If the source supports incremental changes the changeset can directly be generated from that information. | ||
11 | 9 | ||
12 | The changeset is then simply inserted in the regular modification queue and processed like all other modifications. | 10 | Processing of commands happens in the pipeline which executes all preprocessors ebfore the entity is persisted. |
13 | The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store. | ||
14 | 11 | ||
15 | # Preprocessors | 12 | # Preprocessors |
16 | Preprocessors are small processors that are guaranteed to be processed before an new/modified/deleted entity reaches storage. They can therefore be used for various tasks that need to be executed on every entity. | 13 | Preprocessors are small processors that are guaranteed to be processed before an new/modified/deleted entity reaches storage. They can therefore be used for various tasks that need to be executed on every entity. |
@@ -106,7 +103,7 @@ The indexes status information can be recorded using the latest revision the ind | |||
106 | Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail). | 103 | Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail). |
107 | It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in. | 104 | It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in. |
108 | 105 | ||
109 | The domain types provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented. | 106 | The domain type adaptors provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented. |
110 | It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections. | 107 | It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections. |
111 | 108 | ||
112 | ## Preprocessors generating additional entities | 109 | ## Preprocessors generating additional entities |
@@ -116,3 +113,11 @@ In such a case the preprocessor must invoke the complete pipeline for the new en | |||
116 | 113 | ||
117 | # Pipeline | 114 | # Pipeline |
118 | A pipeline is an assembly of a set of preprocessors with a defined order. A modification is always persisted at the end of the pipeline once all preprocessors have been processed. | 115 | A pipeline is an assembly of a set of preprocessors with a defined order. A modification is always persisted at the end of the pipeline once all preprocessors have been processed. |
116 | |||
117 | # Synchronization / Change Replay | ||
118 | * The synchronization can either: | ||
119 | * Generate a full diff directly on top of the db. The diffing process can work against a single revision/snapshot (using transactions). It then generates a necessary changeset for the store. | ||
120 | * If the source supports incremental changes the changeset can directly be generated from that information. | ||
121 | |||
122 | The changeset is then simply inserted in the regular modification queue and processed like all other modifications. The synchronizer has to ensure only changes are replayed to the source that didn't come from it already. | ||
123 | |||