3 ms·

I have a possibly very stupid question: how is this not "basically just Git"? Git is a content-addressable distributed filesystem which represents its history i

I have a possibly very stupid question: how is this not "basically just Git"? Git is a content-addressable distributed filesystem which represents its history immutably and verifiably as a tree of committed transactions. Is the point that you need much more data throughput than Git can handle, or something?

carapace 6y ago
I don't know yet how it will turn out but I'm making a simple prototype DB using Prolog-syntax flat files stored in git. (SWI Prolog provides a specialized `persistency` module that is kind of "log-oriented" ( https://www.swi-prolog.org/pldoc/man?section=persistency https://www.swi-prolog.org/pldoc/man?section=persistency ) but I want to see how well just plain ol' Prolog files work.)
- throwaway_pdp09 6y ago
  Like this https://en.wikipedia.org/wiki/Datalog https://en.wikipedia.org/wiki/Datalog perhaps?
  - carapace 6y ago
    Nah, just plain old Prolog. (I've only been working with Prolog for about a year. I know there are other things out there like Datalog, Mercury, and Kowalski's Logic Production Systems, but I want to grok the root in fullness before I get to those.)
dustingetz 6y ago
You need graph queries and graph transactions basically, git is geared for text and diffing
- Smaug123 6y ago
  Well, yes and no - while it does provide diffing, it's not native to how Git works. Diffs are inferred, or are used internally as a performance optimisation, rather than being fundamental. I suspect this is the kind of place where the answer is "just go and do it, you'll find out why soon enough".
  - ChristianBundy 6y ago
    I work on Scuttlebutt, which in another "basically just Git" kind of thing, and after porting Scuttlebutt to "just Git" I can comment on this a bit. Git is a hash chain with a few constraints: - Each commit has at least one previous commit, unless it's the root. - Each commit has author and committer metadata with embedded timestamps. - Each commit references a merkle tree of files at that specific commit. You have the option of setting the authors to some minimal example value (example@example.com, Jan 1 1970) and using an empty tree, but then your payloads are being stored in the "commit message". Streaming these payloads is hard, getting them by sequence numbers is hard, enforcing extra constraints (e.g. only one previous commit, no merges) requires a Git hook, and at all times you're acutely aware that Git wasn't built to act as a distributed NoSQL database. Using Git as a database is possible, but I think it's about as practical as writing your application logic in some technically-Turing-complete language like PostScript.

carapace 6y ago

I don't know yet how it will turn out but I'm making a simple prototype DB using Prolog-syntax flat files stored in git. (SWI Prolog provides a specialized `persistency` module that is kind of "log-oriented" ( https://www.swi-prolog.org/pldoc/man?section=persistency https://www.swi-prolog.org/pldoc/man?section=persistency ) but I want to see how well just plain ol' Prolog files work.)

throwaway_pdp09 6y ago
Like this https://en.wikipedia.org/wiki/Datalog https://en.wikipedia.org/wiki/Datalog perhaps?
- carapace 6y ago
  Nah, just plain old Prolog. (I've only been working with Prolog for about a year. I know there are other things out there like Datalog, Mercury, and Kowalski's Logic Production Systems, but I want to grok the root in fullness before I get to those.)

dustingetz 6y ago

You need graph queries and graph transactions basically, git is geared for text and diffing

Smaug123 6y ago
Well, yes and no - while it does provide diffing, it's not native to how Git works. Diffs are inferred, or are used internally as a performance optimisation, rather than being fundamental. I suspect this is the kind of place where the answer is "just go and do it, you'll find out why soon enough".
- ChristianBundy 6y ago
  I work on Scuttlebutt, which in another "basically just Git" kind of thing, and after porting Scuttlebutt to "just Git" I can comment on this a bit. Git is a hash chain with a few constraints: - Each commit has at least one previous commit, unless it's the root. - Each commit has author and committer metadata with embedded timestamps. - Each commit references a merkle tree of files at that specific commit. You have the option of setting the authors to some minimal example value (example@example.com, Jan 1 1970) and using an empty tree, but then your payloads are being stored in the "commit message". Streaming these payloads is hard, getting them by sequence numbers is hard, enforcing extra constraints (e.g. only one previous commit, no merges) requires a Git hook, and at all times you're acutely aware that Git wasn't built to act as a distributed NoSQL database. Using Git as a database is possible, but I think it's about as practical as writing your application logic in some technically-Turing-complete language like PostScript.