3 ms·

That isn't how CRDT's work though. In the example of mutating a bank balance, there would be addition operations and subtraction operations. So /eventually/ all

That isn't how CRDT's work though. In the example of mutating a bank balance, there would be addition operations and subtraction operations. So /eventually/ all nodes would arrive at the same balance. It's a bit like event sourcing but lower-level.

michaelmior 4y ago
Depends on the type of CRDT. You can have a CRDT which supports setting a register (or column value in a row) to a particular value. This is what Crsql appears to do as one sibling comment indicated. There are a number of ways to resolve conflicting updates, but Crsql chooses LWW (last writer wins).
bawolff 4y ago
Right, but its how SQL works. So did this project get rid of SQL? What does it mean in context to join SQL and CRDTs together?
- pbalau 4y ago
  You don't update the account.ballance, you insert a new transaction for that account with the amount required. At eod, you calculate and update the correct balance.
- nbevans 4y ago
  That isn't necessarily "how SQL works". Sure, you might design your schema like that. But many accounting systems don't necessarily store a "balance" except perhaps as a performance optimisation. They derive the balance from the history of transactions that have occurred on an account. And a transaction is, essentially, a + or - value. Indeed it can be argued that CRDTs are a natural fit for SQL because it is essentially a derivative of set theory
  - bawolff 4y ago
    If you are essentially going to just have inserts that are not dependent on any reads, why are you bothering with fancy algorithms like CDRT? That is the trivial case.
  - fauigerzigerk 4y ago
    I think the question is whether this particular CRDT has any notion of transactions to make sure the database is left in a consistent state after a merge. As I understand it, the only guarantee we get from all CRDTs is that all copies end up in the same state irrespective of merge order. And then there are some trivial examples, like counters, where this state is also logically consistent. But that is not guaranteed in general. So what about the classical example of transferring an amount from account A to account B if account A has sufficient funds? I think for a CRDT to support such cases (for arbitrary schemas) it would have to have some notion of atomicity and some way to specify preconditions.

michaelmior 4y ago

Depends on the type of CRDT. You can have a CRDT which supports setting a register (or column value in a row) to a particular value. This is what Crsql appears to do as one sibling comment indicated. There are a number of ways to resolve conflicting updates, but Crsql chooses LWW (last writer wins).

bawolff 4y ago

Right, but its how SQL works. So did this project get rid of SQL? What does it mean in context to join SQL and CRDTs together?

pbalau 4y ago
You don't update the account.ballance, you insert a new transaction for that account with the amount required. At eod, you calculate and update the correct balance.
nbevans 4y ago
That isn't necessarily "how SQL works". Sure, you might design your schema like that. But many accounting systems don't necessarily store a "balance" except perhaps as a performance optimisation. They derive the balance from the history of transactions that have occurred on an account. And a transaction is, essentially, a + or - value. Indeed it can be argued that CRDTs are a natural fit for SQL because it is essentially a derivative of set theory
- bawolff 4y ago
  If you are essentially going to just have inserts that are not dependent on any reads, why are you bothering with fancy algorithms like CDRT? That is the trivial case.
- fauigerzigerk 4y ago
  I think the question is whether this particular CRDT has any notion of transactions to make sure the database is left in a consistent state after a merge. As I understand it, the only guarantee we get from all CRDTs is that all copies end up in the same state irrespective of merge order. And then there are some trivial examples, like counters, where this state is also logically consistent. But that is not guaranteed in general. So what about the classical example of transferring an amount from account A to account B if account A has sufficient funds? I think for a CRDT to support such cases (for arbitrary schemas) it would have to have some notion of atomicity and some way to specify preconditions.