Hacker News new | ask | show | jobs
by marknadal 4131 days ago
This person (in the comments below, please upvote him), and my reply, best addresses the most important questions: https://news.ycombinator.com/item?id=9077969

But to address your other comments:

Why can't a transaction log be commutative? You just have to make sure to be explicit about the ordering of events (like by using linked lists or progressively incremented hashes). This is the realm for CRDTs and stuff though, which GUN core doesn't touch.

Yes the HAM deals with merging any two logs/streams/history, any two snapshot/states, but also merging any log/stream/history with any snapshot/state.

This is important, because it allows you to merge more than just two, you just have to do it serially (in any order). That merge algorithm guarantees the deterministic resolution (see the comment link I posted above).
1 comments
sseveran 4131 days ago
It relies on the data being commutative. If the data is not commutative then we need, wait for it, drum roll please, some consistency, which by your own admission is not provided. The consistency is the hard part which is why there is an entire field of study on just this problem.

I fail to see how your merge algorithm is deterministic in case of failures.

link
karlgrz 4131 days ago
You -cannot- have a distribute database without consistency. Prove us ALL wrong, please.
link
marknadal 4131 days ago
Maybe I wasn't clear... GUN does have Eventual consistency, but not strong/global consistency.

Aka GUN is AP and Eventually consistent. You manually at the application layer can decide to lock, sacrificing Availability, and get strong consistency.

The merge algorithm works in an Eventually consistent case, but obviously is too naive for global Consistency, you'd need some form of consensus.

Or does that not address your comment?

link