Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

realm.io

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#61

Post by gritzko »

astigsen wrote: post #35
nolanl wrote: post #31

Earlier quoted context omitted.

(I also work on PouchDB.) For "conflict-free sync," according to the docs, this appears to be last-write-wins along with a special case for deletes: https://realm.io/docs/realm-object-server/#conflict-resoluti... . (Incidentally Couch/Pouch also has a special case for deletes, but it does the opposite behavior by default – deletions lose to updates.) There's also some language in here about how "insertions in lists a…

Realms approach to conflict resolution is very different from what you see in products like Couch. Realm is an _object_ database, so in contrast to document databases where conflict resolution happens very coarse grained at the document level, in Realm it happens at the object level (and actually all the way down into individual properties). This essentially means that the entire object graph is treated as one big CR…

An-object-graph-as-a-CRDT is a really interesting concept. So far, I am not aware of any literature formalizing/studying it. I can only recall the recent CRDT JSON paper by Kleppmann et al, which is significantly less ambitious. Is your approach documented?

While reading the announce, my first guess was some recursive per-field LWW, but you mentioned vector clocks. That is intriguing.

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#62

Post by gritzko »

striking wrote: post #51
janl wrote: post #48

Earlier quoted context omitted.

How is "conflict-free sync" done? The usual approach is last-write-wins, which is just a euphemism for "randomly losing user data", or CRDTs or Operational Transforms, which severely limit the data models one can sync. I'm happy to learn about a silver bullet here.

CRDT, but also vector clocks. https://news.ycombinator.com/item?id=12590753

Some CRDTs employ vector clocks. CRDT is a veeeeery broad family of algorithms and data structures.

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#63

Post by striking »

gritzko wrote: post #62
striking wrote: post #51

Earlier quoted context omitted.

CRDT, but also vector clocks. https://news.ycombinator.com/item?id=12590753

Some CRDTs employ vector clocks. CRDT is a veeeeery broad family of algorithms and data structures.

Is that not what I stated (even if it was poorly phrased, and I can no longer edit it)?

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#64

Post by simonask »

marknadal wrote: post #45
timanglade wrote: post #44

Earlier quoted context omitted.

See the full answer from Realm’s founder/CEO here: https://news.ycombinator.com/item?id=12590753

Thanks, did not see that. Not all vector clocks provide conflict resolution though - actually, they can very much lack in this regard. For instance, you are much more likely to get two clients that increment to the same vector while offline than two clients getting the exact same millisecond timestamp. Which would make the problem worse, not resolved. What type of vector are you using?

Simon from Realm here - just wanted to chime in and clarify some details on this. It would be more correct to say that we are using Lamport timestamps, with the addition of a globally unique ID for each client and some tracking of changeset ancestry. No two identical [timestamp, id] tuples will ever be produced in our system, so there is always an unambiguous way to decide which side "came first" in case of a causally unrelated conflict.

It's important to understand that most "conflicts" in our system are resolved without resorting to timestamps at all, which is possible due to the way we encode our changesets on the wire and the fact that we track their ancestry. It is only used in cases where we absolutely have to, i.e. when there is no causal relationship between two updates of the same property (in which case, the "later" timestamp wins).

Hope that answered your question. :-)

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#65

Post by marknadal »

simonask wrote: post #64
marknadal wrote: post #45

Earlier quoted context omitted.

Thanks, did not see that. Not all vector clocks provide conflict resolution though - actually, they can very much lack in this regard. For instance, you are much more likely to get two clients that increment to the same vector while offline than two clients getting the exact same millisecond timestamp. Which would make the problem worse, not resolved. What type of vector are you using?

Simon from Realm here - just wanted to chime in and clarify some details on this. It would be more correct to say that we are using Lamport timestamps, with the addition of a globally unique ID for each client and some tracking of changeset ancestry. No two identical [timestamp, id] tuples will ever be produced in our system, so there is always an unambiguous way to decide which side "came first" in case of a causall…

Awesome. Thanks!

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#66

Post by mamcx »

I wanna build a POS app and need a solid sync experience. I'm building my own but obviously prefer to use something else ;)

This could support multiple users against a master database editing and getting up-to-date(as possible) data? And sync reliable?

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#68

Post by jlu »

simonask wrote: post #64
marknadal wrote: post #45

Earlier quoted context omitted.

Thanks, did not see that. Not all vector clocks provide conflict resolution though - actually, they can very much lack in this regard. For instance, you are much more likely to get two clients that increment to the same vector while offline than two clients getting the exact same millisecond timestamp. Which would make the problem worse, not resolved. What type of vector are you using?

Simon from Realm here - just wanted to chime in and clarify some details on this. It would be more correct to say that we are using Lamport timestamps, with the addition of a globally unique ID for each client and some tracking of changeset ancestry. No two identical [timestamp, id] tuples will ever be produced in our system, so there is always an unambiguous way to decide which side "came first" in case of a causall…

Thanks for the details, just wondering is the implementation mentioned here available to review somewhere? Is it included in the realm core repo?

Re: Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database

#69

Post by reallarry »

mamcx wrote: post #66

I wanna build a POS app and need a solid sync experience. I'm building my own but obviously prefer to use something else ;) This could support multiple users against a master database editing and getting up-to-date(as possible) data? And sync reliable?

Sure looks like it does.
Post reply on HN