« BackSQLite transactions and virtual tablesmisfra.meSubmitted by preetamjinka 4 days ago
  • dvektor 3 days ago

    Love to see someone writing about vtabs, I implemented vtab support for a rust reimplementation of sqlite so I've recently learned a tremendous amount about them. They are very powerful and probably under utilized.

    • Jupe 3 days ago

      Interesting. But this uses mattn's go-sqlite3 package, which is CGO.

      Is this a normal/expected requirement in modern GO?

      • ncruces 3 days ago

        Virtual tables are fully supported by my CGO free driver: https://pkg.go.dev/github.com/ncruces/go-sqlite3

        You can have a look at a bunch of examples in my extensions folder: https://github.com/ncruces/go-sqlite3/tree/main/ext

        PS: The mattn CGO driver actually doesn't seem to support wrapping the xBegin/xSync/xRollback/xCommit methods. Mine actually does, although it's largely untested, as I haven't needed this yet.

        • preetamjinka 3 days ago

          We use mattn's go-sqlite3 in our SaaS product. It's not ideal from a toolchain perspective (i.e. cross compiling becomes a little annoying, especially with multi-arch Docker images) but once you get across that hurdle, we haven't run into any major problems with cgo.

          • hamburglar 3 days ago

            The problem with cgo is it reduces portability, not that it causes issues. If whatever C you’re invoking doesn’t build on your architecture or if you need to cross-compile (last I checked), you’re out of luck.

            • cryptonector 3 days ago

              I bet SQLite3 builds on more platforms than Go.

              • catlifeonmars 3 days ago

                It’s not about the build platform, it’s about the execution platform and not having to have a toolchain for every platform. This is especially relevant in the embedded space.

          • cryptonector 3 days ago

            There is no pure Go implementation of SQLite3 so...