|
|
|
|
|
by ofriw
480 days ago
|
|
Yup. Go ahead and try it, then you'll discover that: - The queue introduces delays so this doesn't play nice with modern collaborative editing experience (think google docs, slack, etc) - Let's say change A set a field to 1, and change B set the same field to 2. GoatDB allows you to easily get either 1, 2 or 3 (sum) or apply a custom resolution rule Your only choices before goat to solve this were: Operational Transformation, raw CRDTs or differential synchronization. GoatDB combines CRDTs with commit graphs so it can do stuff other approaches don't at an unmatched speed |
|
I tried it and much more a long time ago.
The queue introduces delays so this doesn't play nice with modern collaborative editing experience
Things that can be done millions of times per second per core don't "introduce delays" that a handful of people are going to see.
unmatched speed
Are you seriously trying to say that the database you created in a scripting language that uses linear scanning of arrays is 'unmatched' compared to high performance C++? You may have other features but you have no benchmarks and the scenario you were bragging about is trivial.