Add a CRDT with a suffix of _register which is represented by a tuple of [stamp, data] where:
stamp is a number, it may be a floating point timestamp (in seconds), integer timestamp in milliseconds, or an integer version of the data, as long as these values are not used interchangeably for the same key
data is arbitrary JSON value (but should be kept small, as it is always in memory in swindon)
The update rules are: if stamp has higher value, update the data, if not drop the update. On equal values, it's unspecified of whether the value should be updated or not.
Note: this update algorithm is a lot less strict than in other types and can produce different values on different nodes.
Motivation
While most of the time you should avoid last write wins strategy. For some things it's inevitable. For example for setting status of the user.
In cases where status is stored in a database, it's better to keep a version of the status in a database. And if the status is large enough, it's better to use lattice with a counter and fetch status when version changes. That keeps memory usage of swindon itself smaller.
Specification
Add a CRDT with a suffix of
_registerwhich is represented by a tuple of[stamp, data]where:stampis a number, it may be a floating point timestamp (in seconds), integer timestamp in milliseconds, or an integer version of the data, as long as these values are not used interchangeably for the same keydatais arbitrary JSON value (but should be kept small, as it is always in memory in swindon)The update rules are: if
stamphas higher value, update the data, if not drop the update. On equal values, it's unspecified of whether the value should be updated or not.Note: this update algorithm is a lot less strict than in other types and can produce different values on different nodes.
Motivation
While most of the time you should avoid last write wins strategy. For some things it's inevitable. For example for setting status of the user.
In cases where status is stored in a database, it's better to keep a version of the status in a database. And if the status is large enough, it's better to use lattice with a
counterand fetch status when version changes. That keeps memory usage of swindon itself smaller.