- it's content addresses / merkle DAG all the way down. The commit's hash is something like meta (author, description, timestamp) + parents hash + root value hash. The root value is composed of the schema, and pointers to table and index maps. Tables and indexes are merkle DAGs of the table data organized in a structure a bit like a B-tree, but with cut points chosen by a rolling value hash in order to probabilistically re-synchronize on incremental changes. Some details: https://www.dolthub.com/blog/2020-04-01-how-dolt-stores-tabl... , https://www.dolthub.com/blog/2020-05-13-dolt-commit-graph-an...
- currently table data is stored row major for full rows of the table and so diffing cannot efficiently ignore individual columns.
- direct conflicts are computed on a row-by-row basis, using the primary key of the row. And then constraints and foreign key references are maintained and validated across merges and edits.
Yeah, pgx is quite impressive and is a great set of bindings with very accessible examples, etc. Definitely something to be aware of for people that prefer building things in Rust. Thanks for pointing it out here.
I think the contract in the context package is that WithCancel may leak resources if cancel is not called and the parent context is cancelable but never canceled. At least, that seems to be the behavior I see in the implementation here:
Hi Hacker News! We wrote a short blog post showing how forks and pull requests in DoltHub work in a data collaboration context. It's really neat being able to open a pull request against a SQL database.
When using unsigned ints for backward iteration, I'm partial to looping as:
since it has so much symmetry with forward iteration.