Allow columns to be defined as counters rather than LWW.
Some basic background: https://www.cs.utexas.edu/~rossbach/cs380p/papers/Counters.html
API ideas:
We could use special functions to interact with count columns. E.g.,
UPDATE foo SET counter = crsql_incr(counter, amount)
where crsql_incr takes a counter crdt instance.
@ivertom -- I remember you sketching out ideas for a counter but can't seem to track them down.
Implementation Ideas
Ideally we'll start with the most generic counter -- one that increments and decrements.
We'll need to track two lists of tuples:
// increments
type Increments = [SiteId, count][];
type Decrements = [SiteId, count][];
and the "final" count is simply the sum of increments minus sum of decrements:
increments.reduce((l, r) => l + r[1], 0) - decrements.reduce((l, r) => l + r[1], 0)
https://www.cs.utexas.edu/~rossbach/cs380p/papers/Counters.html#cvrdt-state-based-design-1
The final value is what should always be stored in the column. Backing data (e.g., sites and their counts) should be stored in some auxiliary table.
The auxiliary table could be something as simple as a table called crsql_counters which tracks state for all counters in the system:
CREATE TABLE crsql_counters(
counter_id INTEGER,
site_ordinal INTEGER,
val ANY_NUMBER_TYPE,
type INCREMENT | DECREMENT
);
Issues
- Continuous growth of rows to track a count increment / decrement
Workarounds
- Compact out these rows when all sites are > a given db version
- Save a snapshot of the state at the compaction point
Compacting out history will be a later exercise.
Allow columns to be defined as counters rather than LWW.
Some basic background: https://www.cs.utexas.edu/~rossbach/cs380p/papers/Counters.html
API ideas:
We could use special functions to interact with count columns. E.g.,
UPDATE foo SET counter = crsql_incr(counter, amount)where
crsql_incrtakes a counter crdt instance.@ivertom -- I remember you sketching out ideas for a counter but can't seem to track them down.
Implementation Ideas
Ideally we'll start with the most generic counter -- one that increments and decrements.
We'll need to track two lists of tuples:
and the "final" count is simply the sum of increments minus sum of decrements:
https://www.cs.utexas.edu/~rossbach/cs380p/papers/Counters.html#cvrdt-state-based-design-1
The final value is what should always be stored in the column. Backing data (e.g., sites and their counts) should be stored in some auxiliary table.
The auxiliary table could be something as simple as a table called
crsql_counterswhich tracks state for all counters in the system:Issues
Workarounds
Compacting out history will be a later exercise.