Clarify ORMap docs on replacing entries

This commit is contained in:
James Roper 2019-10-01 14:41:32 +02:00 committed by Patrik Nordwall
parent 681f58677a
commit 6c05bea261

View file

@ -397,6 +397,14 @@ you have not seen. This is the same semantics as for the `ORSet`.
If an entry is concurrently updated to different values the values will be merged, hence the If an entry is concurrently updated to different values the values will be merged, hence the
requirement that the values must be `ReplicatedData` types. requirement that the values must be `ReplicatedData` types.
While the `ORMap` supports removing and re-adding keys any number of times, the impact that this has on the values
can be non-deterministic. A merge will always attempt to merge two values for the same key, regardless of whether that
key has been removed and re-added in the meantime, an attempt to replace a value with a new one may not have the
intended effect. This means that old values can effectively be resurrected if a node, that has seen both the remove and
the update,gossips with a node that has seen neither. One consequence of this is that changing the value type of the
CRDT, for example, from a `GCounter` to a `GSet`, could result in the merge function for the CRDT always failing.
This could be an unrecoverable state for the node, hence, the types of `ORMap` values must never change for a given key.
It is rather inconvenient to use the `ORMap` directly since it does not expose specific types It is rather inconvenient to use the `ORMap` directly since it does not expose specific types
of the values. The `ORMap` is intended as a low level tool for building more specific maps, of the values. The `ORMap` is intended as a low level tool for building more specific maps,
such as the following specialized maps. such as the following specialized maps.