mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 20:47:01 +01:00
30 lines
687 B
ReStructuredText
30 lines
687 B
ReStructuredText
|
|
Don't no-op changes
|
|
-------------------
|
|
|
|
At first glance it may seem correct to no-op a change where the state is:
|
|
|
|
{
|
|
name: william
|
|
}
|
|
|
|
with a "delete name; add name william".
|
|
|
|
However, this doesn't express the full possibities of the replication topology
|
|
in the system. The follow events could occur:
|
|
|
|
::
|
|
|
|
DB 1 DB 2
|
|
---- ----
|
|
n: w
|
|
del: name
|
|
n: l
|
|
del: name
|
|
n: w
|
|
|
|
The events of DB 1 seem correct in isolation, to no-op the del and re-add, however
|
|
when the changelogs will be replayed, they will then cause the events of DB2 to
|
|
be the final state - whet the timing of events on DB 1 should actually be the
|
|
final state.
|