Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

github.com

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#151

Post by TimTheTinker »

laurent92 wrote: post #18

Wordpress would have benefited from this. What a lot of webmasters want is, test the site locally, then merge it back. A lot of people turned to Jekyll or Hugo for the very reason that it can be checked into git, and git is reliable. A static website can’t get hacked, whereas anyone who has been burnt with Wordpress security fail knows they’d prefer a static site. And even more: People would like to pass the new webs…

Sure, but Wordpress is still running PHP files for every page load and back-end query. Dolt would help offload some of the code’s complexity, but that would still leave a significant attack surface area.

In other words, by itself Dolt couldn’t solve the problem of Wordpress not being run mostly from static assets on a server (plus an API).

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#152

Post by lifty »

devwastaken wrote: post #129

Something like this but for sqlite would be great for building small git enabled applications/servers that cana benefit from the features git provides but only need a database and a library to do it.

Noms might be what you’re looking for (https://github.com/attic-labs/noms). Dolt is actually a fork of Noms.

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#153

Post by antman »

scottmcdot wrote: post #55

Dolt might be good but never underestimate the power of Type 2 Slowly Changing Dimension tables [1]. For example, if you had an SSIS package that took CSV and imported them into a database, and one day you noticed it accidently rounded the value incorrectly, you could fix the data and retain traceability of the data which was there originally. E.g., SSIS package writes row of data: https://imgur.com/DClXAi5 Then a fe…

Can't something like that work as SQL:2011 temporal tables?

Postgres equivalent solution in this [0] rather complex but great tutorial

[0]: https://clarkdave.net/2015/02/historical-records-with-postgr...

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#154

Post by edgyquant »

Klwohu wrote: post #131
TedDoesntTalk wrote: post #34

Earlier quoted context omitted.

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.

This is the issue with names. Even though the project is called doit the DoIt stylizing makes it look problematic. It's a non-starter, hopefully the author makes a big change. Just choosing lower case for the project would be enough.

It’s not though it is dolt, meaning a stupid person, like git (stupid simple version control.)

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#155

Post by Hendrikto »

pradn wrote: post #36
strogonoff wrote: post #4

You can also use Git for data! It’s a bit slower, but smart use of partial/shallow clones can address performance degradation on large repositories over time. You just need to take care of the transformation between “physical” trees/blobs and “logical” objects in your dataset (which may not have 1:1 mapping, as having physical layer more granular reduces likelihood of merge conflicts). I’m also following Pijul, which…

Git is too complicated. It's barely usable for daily tasks. Look at how many people have to Google for basic things like uncommitting a commit, or cleaning your local repo to mirror a remote one. Complexity is a liability. Mercurial has a nicer interface. And now I see the real simplicity of non-distributed source control systems. I have never actually needed to work in a distributed manner, just client-server. I hav…

> Git is too complicated. It's barely usable for daily tasks. Look at how many people have to Google for basic things like uncommitting a commit, or cleaning your local repo to mirror a remote one.

Cars are too complicated. They are barely usable for daily tasks. Look at how many people have to Google for basic things like changing a fan belt, or fixing cylinder head gasket.

You can fill in almost anything here. Most tools are complicated. Yet yo don’t need to know their ins and outs for them to be useful to you.

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#156

Post by berkes »

laurent92 wrote: post #18

Wordpress would have benefited from this. What a lot of webmasters want is, test the site locally, then merge it back. A lot of people turned to Jekyll or Hugo for the very reason that it can be checked into git, and git is reliable. A static website can’t get hacked, whereas anyone who has been burnt with Wordpress security fail knows they’d prefer a static site. And even more: People would like to pass the new webs…

At the root of this lies the problem that content, configuration and code is stored in one blurp (a single db). Never clearly bounded nor contained. Config is spread over tables. Usergenerated content (from comments to orders) mixed up with redactional content: often even in tables, sometimes even in the same column. Drupal suffers the same.

What is needed, is a clear line between configuration (and logic), redactional content, and user generated content. Those three have very distinct lifecycles. As long as they are treated as one, the distinct lifecycles will conflict. No matter how good your database merging is: the root is a missing piece of architecture.

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#157

Post by touisteur »

acidbaseextract wrote: post #138
justinclift wrote: post #136

Earlier quoted context omitted.

How do you send someone a dolt database as a file?

How do you send someone a git repository as a file? Why would a tarball not work?

Git bundles. Amazing simple tool. Doing it all the time via sneaker net, or mail/chat-with-attachments, better that sending patches around IME.

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#158

Post by _Wintermute »

TedDoesntTalk wrote: post #34
Klwohu wrote: post #5

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.

Do you know what "git" means?

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#159

Post by StreamBright »

zomglings wrote: post #76

If anyone from the dolt team is reading this, I'd like to make an enquiry: At bugout.dev, we have an ongoing crawl of public GitHub. We just created a dataset of code snippets crawled from popular GitHub repositories, listed by language, license, github repo, and commit hash and are looking to release it publicly and keep it up-to-date with our GitHub crawl. The dataset for a single crawl comes in at about 60GB. We u…

You have other options too. If I have time i can try to reduce the size with a columnar format that is designed for this use case (repeated values, static dataset).

Re: Dolt is Git for Data: a SQL database that you can fork, clone, branch, merge

#160

Post by fiedzia »

codesnik wrote: post #124
fiedzia wrote: post #113

Earlier quoted context omitted.

BTW. I wish all databases versioned their schema and kept full history. This should be a standard feature.

keep history just as a changelog to see when and what was changed? or something with versions you actively can revert to? I suppose one of the problems is that changing schema is usually interleaved with some sorts of data migrations and conversion and those I have no idea how to track without using some general scripting language, like migrations in many frameworks which are already there.

Just storing a changelog would be very useful. I could for example compare db version some app was developed for with current state. Most companies will store schema migrations in git, but doing anything with this information is difficult. Having this in db would make automated checks easier.
Post reply on HN