Problematic name, could become a millstone on the neck of the developer far into the future.
Already I would not use this project because of its name. I’m not offended by it, but I know others will be, and it will only be a matter of time before we have to replace it with something else. So why bother in the first place? I know the name is not DOLT but it is close enough to cause offense. Imagine the N-word with one typo. Would it still be offensive? Probably to some.
Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
131–140 of 185 posts
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#132It'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.
Isnt the mysql log journal* what you are looking for? * I dont remember the exact name but I refer the feature that is used to replicate actions if there was an error.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#133Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#134This is absolutely fascinating, conceptually. However, I'm struggling to figure out a real-world use case for this. I'd love if anyone here can enlighten me. I don't see how it can be for production databases involving lots of users, because while it seems appealing as a way to upgrade and then roll back, you'd lose all the new data inserted in the meantime. When you roll back, you generally want to roll back changes…
I might look at it for work. Compliance requires us to keep track of who made what change when, and who it was approved by in case regulators need it. Right now, this often means making an MR on Git with your snippet of SQL, getting it approved, and then manually executing it. This would let us bring the apply stage in, as well as avoid "that SQL query didn't do exactly what I expected" issues. It's possible to do it…
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#135Earlier quoted context omitted.
Yeah, that sized database is likely to be a challenge unless the computer system it's running on has scads of memory. One of my projects (DBHub.io) is putting effort towards working through the problem with larger sized SQLite databases (~10GB), and that's mainly through using bare metal hosts with lots of memory. eg 64GB, 128GB, etc. Putting the same data into PostgreSQL, or even MySQL, would likely be much more eff…
We have 200 GB databases in dolt format that are totally queryable. They don't work well querying on the web though - you need a local copy to query it effectively. Making web query as fast as local is an ongoing project.
200GB databases for PostgreSQL (etc) isn't any kind of amazing.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#136Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#137Earlier quoted context omitted.
It's not just snapshots though. Dolt actually stores the tables, rows, and commits in a Merkle DAG, like Git. So you get branch and merge. You can't do branch and merge with snapshots. (You also get the full git / github toolbox: push and pull, fork and clone, rebase, and most other git commands)
Yeah it's a neat idea but I struggle to think of good use-cases for merge, other than toy datasets. If I'm working on a service that's sharding millions of users across dozens of DB instances a merge is going to be incomprehensible to understand and reason about conflicts.
I suspect that's simply not the use-case they're targeting. You're thinking of a database as simply the persistence component for your service, a means to an end. For you, the service/app/software is the thing you're trying to deliver. Where this looks useful is the cases where the data itself is the thing you're trying to deliver.
Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#138Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#139Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge
#140Earlier quoted context omitted.
Sure keep in mind that my data is a little old but last time I peeked into the git LFS space it seemed like there were still a few gaps. First, most of my background in this area comes from gamedev so YMMV if the same applies in your use cases. For our usage we'd usually have a repo history size that crossed the 1TB mark and even upwards of 2-3TB in some cases. The developer sync was 150-200GB, the art sync was close…
This is super informative! In my case it’s different since Git isn’t accessed by users directly, rather I’m working on some tools that work on top of Git (on user’s machine). Data is primarily text-based, though sometimes binary assets come up (options for offloading them out of Git are being investigated). So far there were no major issues. I predict degradation over time as repos grow in size and history (Git is no…
If you have binary assets and they don't support merging or regeneration from source artifacts that mandates locking(ideally built into SCM but I've seen wiki pages in a pinch at small scale).