1. 27
  1.  

  2. 6

    I like that this guy is doing. I’ve often used database/sql, usually using the driver by mattn, but I’ve also never tried to take large advantage of what SQLite can do, never having used it in another language other than C#, and that only recently.

    Named parameters alone would be worth having generic support for, and I’d be interested to see what other SQLite features I’ve been missing out on.

    1. 2

      I really like the sqlite-lite driver for go: https://github.com/bvinc/go-sqlite-lite

      1. 2

        This is kinda off-topic, but thinking about the nice single-blob executables I see from a lot of Go programs, I kinda wonder if we could go ahead and also stick a SQLlite DB onto them as well–like, have an in-memory database backed by the data section of the executable and then write out to it.

        1. 3

          I’ve wondered about this as well, but aside from the technical aspects I don’t think this is a good idea because it’s very surprising/bad UX. Normally rm program is a safe operation, but now you risk losing data. Also how will upgrades work, etc.? All in all it seems more trouble than it’s worth to me.

          1. 1

            You nerd sniped me a bit. While I don’t see a simple way to use an array of bytes as a vfs, I do see a vfs for putting a sqlite db at the end of an executable. https://www.sqlite.org/src/file/ext/misc/appendvfs.c

          2. 1

            To avoid this I tend to interpose an object that stores a mapping of query strings to *sql.Stmt objects, so I can use the query string itself inline in hot-path as the name of the statement. Experience with this suggests it works,

            I found no improvement from caching prepared statements in the tests I did.

            1. 1

              How did you test?

              1. 1

                I used mattn’s driver, set up an http server (wrote a simple http handler) and then used apache ab to test a bunch of different scenarios.

                1. 1

                  I meant “what were the scenarios?”

            2. 0

              We could have used the C code. SQLite has a high quality reputation and did rock for many years and keep rocking.

              But it did not fit the Go and Rust culture to RIIR/RIIG (rewrite everything from scratch) to be as pure as possible.

              1. 11

                This is actually the opposite of what’s happening here though. The Go stdlib has a builtin package for interacting with SQL databases in an abstract way; this is a C SQLite binding which sacrifices the ability to use this abstraction in order to essentially modify this API in a way which is much more semantically close to the C library semantics (largely by removing the failure surfaces in the abstraction layer that don’t exist for a non-networked database) while preserving the overall design. There’s not any reimplementation of SQLite going on here.

                1. 3

                  Indeed, not a full rewrite. I was worried about replicating the efforts of SQLite. I read the articles without looking at the code, and there was no mention of using the existing SQLite code base.

                  The source makes this entirely obvious: https://github.com/crawshaw/sqlite

                  This is a very neat project.

                2. 5

                  It’s unclear what point you’re trying to make here.

                  1. 3

                    I was mistaken on what the author did. It is not a rewrite of the entire SQLite libraries.

                  2. 2

                    The main reason to implement sqlite in native Go sure is indepence from C. With a language native implementation you’re able to build static binaries for example (assuming you’re not using any other c dependencies).

                    You’d be unable to do that with dependencies to sqlite c-libs.

                    But I agree that sqlite has a reputation for rock solid code for a reason. But a subset of sqlite in a new implementation might be doable and probably good enough for a lot of people.

                    1. 3

                      Oh, it looks like it’s still using the sqlite c source, so that’s that.

                      1. 2

                        Sorry if I provoked confusion.

                      2. 2

                        You’d be unable to do that with dependencies to sqlite c-libs.

                        it is easy to statically link C libs. to the linker, there’s no difference between C and Go (or C++ or D or whatever).