It requires a different primary key than an autoincrementing integer. One popular choice is to use a tuple of (peer_guid, incrementing integer). Or a randomly generated GUID, or a hash of the associated data.

Then each event is associated with zero or more "parent events".

- An event has 0 parents if it is the first change

- An event has 1 parent if it simply came after that event in sequence

- And if an event merges 2 or more branches in history, it says it comes after all of those events

You can also think about it like a set. If I know about events {A, B, C} and generate event D, then D happens-after {A, B, C}. (Written {A,B,C} -> D). But if A->B, then I only need to explicitly record that {B,C} -> D because the relationship is transitive. A -> B -> D implies A -> D.

▲

shakna 4 days ago | parent [-]

And the moment you need to merge, unrepresentable states become possible.

There are techniques to make it less painful, but it will still be possible.

▲

tempodox 4 days ago | parent [-]

You mean, like attempting to merge contradictory states? You will need some resolution stategy then, but in general that would be application-specific, and sometimes it may not exist.

▲

shakna 4 days ago | parent [-]

Okay... But we're now back to invalid states being possible. Tagging with time isn't enough.

	▲	josephg 4 days ago \| parent [-]
		It isn’t enough for what? What are you trying to do? There may be a way to solve whatever problem you have, but without specifics it’s impossible to tell.