4 ms·

Here's the important piece of information, from the conflict resolution page: "Compare their string values with JSON.stringify, choosing the greater of the two

by mark242 10y ago

Here's the important piece of information, from the conflict resolution page: "Compare their string values with JSON.stringify, choosing the greater of the two." In other words -- don't ever use this database in production. on edit: Here's why. CouchDB, which is also an AP database, puts conflict resolution into the hands of the user, but each document contains a revision, including information for the user to determine which is the correct revision. Many times, it's just "the correct one is the most recent one", but that's done in the user's code. Making this kind of assumption (stringify and string comparison) for conflict resolution is dangerous because there will be scenarios when you will lose data no matter how many times you post to the database, guaranteed. Yes you can't be consistent, but you need to tell the user that there's a data conflict and have them deal with the logic.

marknadal 10y ago
Lexical comparison is only used when 2 writes happen at the exact same time. Yes, it is a very basic hybrid vector/lexical/timestamp CRDT. The naive-ness of it is also its power, because it has strong eventually consistent guarantees. However, it is intended to be the base case. You can build your own custom CRDTs on top to handle more specific business logic. For instance adding a DAG, a ledger, a simple linked list, etc. gun's default algorithm is not a silver bullet but it does "just work" out of the box for many web cases. See more here: https://github.com/amark/gun/wiki/Conflict-Resolution-with-Guns https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... . Please especially read about our CAP tradeoffs (see the sidebar on the wiki). Finally, it should be noted that because gun uses a graph data structure, JSON.stringify only ever applies to atomic primitive values (not complex/compound objects). So it is safe to apply (it is NOT safe to apply to complex objects).
- sagichmal 10y ago
  > Lexical comparison is only used when 2 writes happen at the exact same time. But you take time from the system. Your writes may converge, but to an nondeterministic state.
  - marknadal 10y ago
    No, because we then offset it with a vector relative to the machine, even the great Kyle Kingsbury (Aphyr of Call Me Maybe Jepsen tests) tweeted about us about this fact (that we assume/treat time as being loose/unsafe): https://twitter.com/aphyr/status/646302398575587332 https://twitter.com/aphyr/status/646302398575587332 .

by mark242 10y ago

marknadal 10y ago

Lexical comparison is only used when 2 writes happen at the exact same time. Yes, it is a very basic hybrid vector/lexical/timestamp CRDT. The naive-ness of it is also its power, because it has strong eventually consistent guarantees. However, it is intended to be the base case. You can build your own custom CRDTs on top to handle more specific business logic. For instance adding a DAG, a ledger, a simple linked list, etc. gun's default algorithm is not a silver bullet but it does "just work" out of the box for many web cases. See more here: https://github.com/amark/gun/wiki/Conflict-Resolution-with-Guns https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... . Please especially read about our CAP tradeoffs (see the sidebar on the wiki). Finally, it should be noted that because gun uses a graph data structure, JSON.stringify only ever applies to atomic primitive values (not complex/compound objects). So it is safe to apply (it is NOT safe to apply to complex objects).

sagichmal 10y ago
> Lexical comparison is only used when 2 writes happen at the exact same time. But you take time from the system. Your writes may converge, but to an nondeterministic state.
- marknadal 10y ago
  No, because we then offset it with a vector relative to the machine, even the great Kyle Kingsbury (Aphyr of Call Me Maybe Jepsen tests) tweeted about us about this fact (that we assume/treat time as being loose/unsafe): https://twitter.com/aphyr/status/646302398575587332 https://twitter.com/aphyr/status/646302398575587332 .