Dolt is Git for Data

What kind of merge actually happens, e.g. how does it deal with conflicts? Does it merge at the SQL command level or at the changed tuple level?

If I have

    name   job age
    remram dev 32

and I concurrently do

    UPDATE table SET age = age + 2 WHERE job = 'dev';
    UPDATE table SET job = 'mgr' WHERE age = 32;

Do I get a conflict? Do I get something consistent with the two transactions serialized, e.g. dev 34 or op 32)? Can I get something that no ordering of transaction could have given me, like mgr 34?

Merge is cell-wise. If the two heads being merged edited disjoint cells, there's no conflict, they merge together. If they touched the same cell, or if one branch deleted a row another added, then you get a conflict.

Merge conflicts are stored in a special system table so you can decide what to do with them, kind of analogous to conflict markers in a source file. More details here:

https://docs.dolthub.com/sql-reference/version-control/merge...

The situation you're talking about with two transactions isn't a merge operation, it's just normal database transaction isolation level stuff. Dolt supports REPEATABLE_READ right now, with others coming in future releases. So in the example above, whichever transaction committed last would fail and get rolled back (assuming they touched the same rows).

> The situation you're talking about with two transactions isn't a merge operation, it's just normal database transaction isolation level stuff

I mean, arguably. It's not like there is a standard definition for "merge operation" on data. Even Git tries to do more than line-level changes, taking context into account, and turning one line change into two line changes if merging across a file copy for example.

Dolt markets itself as "a version controlled SQL database", so I think it is perfectly reasonable to consider the standard that already exists for concurrent changes to a SQL database, and that's transaction isolation.

I guess anything more complex than this would be pretty unwieldy though, with probably little benefits. I am struggling to come up with a good example for the kind of anomaly I imagine.

You're thinking too small. The transaction is generally not the unit you want to apply version control to, databases already have robust concurrency support at that level.

What you want is to have branches on your data that have many transactions applied to them, for days or weeks. Then you merge the branch back to main when it's ready to ship.

An early customer built pull requests for their configuration application using Dolt, read more here:

https://www.dolthub.com/blog/2021-11-19-dolt-nautobot/