Welcome to HackerNews. The front page doesn't have to be plagued with flat/material design boostrap themes, Wired.com garbage and TechCrunch articles about startups that are written by the startup's founders.
Databases are a ton of fun to read and talk about. If I ever have an event in my life that means I won't have to work anymore I'll spend the majority of my time studying databases.
The next time you're cussing at Microsoft Word for being slow while you type out a paragraph, think about SQLite and how it manages to do sub-millisecond queries to something that is just a file on your file system. Wow!
Doesn't seem that odd to me. I love stumbling on things like that. Makes me learn a bit of something I wouldn't have learnt otherwise. I think this kind of knowledge is of common interest to so called "hackers" or people that like to know how things work.
The format is amazing, however the document is not well written. You have to read about half of it to begin to understand how the format works. I had to read it whole for a project and it was really time consuming, though I don't think I could write it any better than it is right now.
There were some blog posts that were far clearer to understand the file format, but unfortunately I lost track of them.
I've grown to like the SQLite documentation to the brink of adoration. It reads verbose but has a certain mathematical succinctness and completeness to it.
Took me some time to get used to, and yes, you always have to read the entire paragraph.
In the unlikely case that this is intentional it's genius:
it doesn't let you get away with "what do I need to know to make this code compile/kinda-sorta-run", but almost forces you to at least notice the things you should know when using it (protecting you from dangerous half-knowledge).
I'm not sure if this is perfect for file format documentation, but I would guess that a more "traditional" presentation would answer certain questions faster - such as "oh! this looks easy" / "this will take me weeks to work through", or "no, they don't seem to use RFC455692673 index optimization". However, for actually uisng the format for something productive, the time invested would be about the same.
All in all, SQLite is a pleasure to work with, and that's something outstanding on its own.
As a pedagogical exercise, to help me understand the design, I wrote some Go code to read a sqlite database and dump table contents. I remember having to peek at the source code to figure out a few things that weren't explained well in that document.
I'd previously written code to read the lucene database format (python code that time), which was also a good learning experience. I ended up leveraging some of that knowledge for a work project.
And I've also played around with reading/writing git archives.
I'd like to improve the document so that reference to the SQLite source code is not required. Can you explain (perhaps via private email) what the file format document did not describe sufficiently for you to implement a reader in Go?
It was over a year ago, so my memory is a little fuzzy. I do remember that near the end of the process I looked at the source code to answer a question or two. I'll skim over the docs again and see if I can remember what I was confused about.
