To enhance their performance, modern applications typically maintain a cache with a local copy of their data, which they update when there are changes. There may be scenarios to completely refresh the cache data on each change. But when working with large amounts of data, each full refresh imposes a performance penalty. Since the need to update is only for changed data, in many scenarios refreshing only the recent data is enough. This can be achieved by using a caching mode called incremental.

Incremental caching is a way to limit the refreshing of the local cache of a client to only the changed data of the server, based on a timestamp. For each table that incremental caching is desired for, a timestamp column should be added. Then every time in one of those tables a row is inserted or modified, its value on the timestamp field should be set or updated accordingly. If that column is provided and incremental caching is enabled, the rest is done automatically.

How to enable it

In C1ConnectionStringBuilder, incremental caching is provided through two properties:

The following example enables incremental caching for a data source of OData, by setting IncrementalUpdate property to true:

C1ODataConnectionStringBuilder builder = new C1ODataConnectionStringBuilder();
builder.IncrementalUpdate = true;

Relevant scenarios

Incremental caching typically applies in two scenarios:

• Insert only: When records are of historical nature, after being inserted in a table they do not change. The application needs to regularly append new records to the cache, in combination with periodical (e.g. weekly/overnight) refresh of the complete cache, to enhance performance over time. In this case, the data source needs to maintain a unique incremental identifier, and each time determine which records need appending by checking if their identifier is greater than the last identifier in the cached data.

• Insert and update: When already inserted records get modified, the application needs to both append new records to the cache and refresh modified ones. In this case, the data source needs a field to serve as a timestamp, indicating both insertions and modifications, and each time determine which records need updating by checking if their timestamp is later than the last update of the cached data.

To query changed records after performing modifying operations (Insert/Update/Delete) on a table, implicit cache can be used. When modifying a table in the data source, the corresponding table in local cache will be marked over tolerance time. In offline mode, tolerance time is still considered. If the table exists, but not in tolerance time, then an exception is thrown.