3 ms·
That requires a different primary key than the time then, no?
by shakna 1y ago
That requires a different primary key than the time then, no?
- josephg 1y agoIt 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 1y agoAnd 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 1y agoYou 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.