3 ms·
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
by zachmu 4y ago
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/ https://www.dolthub.com/blog/2021-11-19-dolt-nautobot/
- remram 4y agoPlease don't tell me what I'm thinking or what I want to do ;-) The use case I had in mind is closer to a data.world or dbhub, collaborative data cleaning (which often include bulk operations) rather than merging OLTP databases after days or weeks of changes. What I would use now is a script or Jupyter Notebook checked in Git, where cells are strongly ordered and if someone sends me a pull request (changing the code) I have to re-run the notebook to obtain the "merged dataset". I can't say that I have a use for Dolt but it is definitely cool tech.
- zachmu 4y agoIf you're a data cleaning guy, you might be interested in our data bounties program. It's collaborative data importing / cleaning. The current one is building a catalog of museum collections. We launch a new one every month. https://www.dolthub.com/blog/2022-06-14-announcing-museums-bounty/ https://www.dolthub.com/blog/2022-06-14-announcing-museums-b...