Comment by dathinab | Hacker News Reader

Comment by dathinab | Hacker News Reader

Parent Full thread

I think the reason why it's not discussed that much is because a lot of software gave up on properly synchronizing changes and go with a "handwaving eventual consistency" approach for a lot of things.

Furthermore decisions about which db is used are rarely driven by the synchronization model. Except maybe sometimes the question "eventual consistency yes/no/a bit only".

And in academia (wrt. common use-cases) we do have a bunch of well analyzed ways to archive synchronization the main question often isn't one of academic research needing to be done but of which model with which parameters and implementation details on top to use for a specific kind of db. Which mainly is discussed by devs when writing new dbs, i.e. not a everyday thing. While for the many new sqlite sync approaches the answers is nearly always "handwaving eventual consistency", cause nothing else would work on the edge anyway.

> "handwaving eventual consistency" approach for a lot of things.

Which, for some systems translates to: It will be in sync when all the entropy in the universe is gone.

it's also a bit of an red hearing argument

sure some systems under correct operation will never ever be fully in sync as long as they are used

but most systems also do not need to be ever fully in sync

it's good enough that for a specific context they will be in sync in not to much time if that context stops changing

and that is something they do provide

e.g. after updating a JSON blob stored under a specific id that update will be eventually available in the not too distant future and if no future changes to that document happen then in the context of that document the system will be fully in sync. But because you have very man documents there will always be a document which isn't yet in sync and in turn the system as a whole will never be fully in sync. But in the end that doesn't really matter.

Also: no computer system will live that long, and if they aren't put in sync before they stop working they will literally never be fully in sync.

TLDR: make it a Someone Else's Problem, in other words "not synced? Our code works as designed, go bother Support, or whatever."

no its not somones else problem

it's still your system

but a system as a whole never being fully in sync is a red herring argument which misses the point and focuses on an aspect which might sound like a problem but hardly ever is a problem at all

Reply on news.ycombinator.com