Making a change to SQLite source code

What a nice blogpost! I really enjoyed how Bruno leads us through the whole process including his thoughts and strategies to find the code that needs to be modified and how to do it. Luckily the problem - how to get the bytes of a sqlite record - is small enough in scope to solve in a readable blogpost. That’s a „genre“ i really enjoy.

Interesting that he could also do purely by reading the code, or at least presents it that way. I might have started by hooking a debugger to the application and seeing where an insert takes me. Guess many roads lead to rome.

Not mentioned is that the full test sqlite test suite is proprietary and you need a super expensive sqlite foundation membership to get access to it. That means (unless you get that membership), your patched/forked version will be less extensively tested than the official version. So sqlite is in reality very difficult to fork. Sqlite is very solid, but bugs do sometimes show up in it despite all that testing, and more relevantly, some bugs in development are presumably caught by the testing, which outsiders don't have access to.

I'm somewhat leery of hacking on sqlite for this reason. It seems to me like a good candidate for RiiR.

Really liked this post. One of the hardest things for me as a junior engineer is navigating complicated codebases and understanding them enough to make the change I want. This gives useful insight on how one might approach a similar problem.

The next blog post can be about how to submit the change to libSQL [1], so other people can take advantage of it.

[1] https://github.com/libsql/libsql

This reminds me: I’m really looking forward to SQLite blob I/O being added to the Golang library. There is an open PR to add it. It will enable a lot of interesting use cases revolving around streaming of blobs rather than storing them in memory.

Would be great to see how this change affects SQLite’s absolutely gargantuan test suite!