This is cool, but the parent dolthub project is even cooler! Dolthub.com
Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
21–30 of 185 posts
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#22Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#23Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#24I collected all the git for data open source projects I could find a few months back, there have been a bunch of interesting approaches https://docs.google.com/spreadsheets/d/1jGQY_wjj7dYVne6toyzm...
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#25Earlier quoted context omitted.
Agreed. I couldn't immediately see if it was "DOLT" or "do it", as in "just do it". It's the former.
I was going back and forth between the two until seeing doLt in terminal font.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#26Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#27It's amazing this isn't a standard feature. The database world seems to have focused on large, high volume, globally distributed databases. Presumably you would't version clickstream or IoT sensor data. Features like this that are only feasible below a certain scale are underdeveloped and I think there's opportunity there.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#28It's amazing this isn't a standard feature. The database world seems to have focused on large, high volume, globally distributed databases. Presumably you would't version clickstream or IoT sensor data. Features like this that are only feasible below a certain scale are underdeveloped and I think there's opportunity there.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#29Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#30That is, you can:
1. Create a table with an extra changeset id column and a branch id column, so that you can keep historical values.
2. Have a view on that table with the latest version of each record on the master branch.
3. Express branching-related actions as actions on the main table with different record versions and branch names
4. For the chocolate sprinkles, have tables with changeset info and branch info
and that gives you a poor man's git already - doesn't it?