xyproto / algernon

Small self-contained pure-Go web server with Lua, Teal, Markdown, Ollama, HTTP/2, QUIC, Redis, SQLite and PostgreSQL support ++
https://algernon.roboticoverlords.org
BSD 3-Clause "New" or "Revised" License
2.79k stars 137 forks source link

SQLite support #134

Closed bearinld004 closed 1 month ago

bearinld004 commented 1 year ago

lighter weight alternative to running postgres and mysql for relational database.

xyproto commented 1 year ago

Thanks for the feature request. There is BoltDB support, which also saves data to a file, but I'll consider also adding in support for SQLite.

Previously, there was no pure Go package that supported SQLite, but I believe there is at least one available now.

bearinld004 commented 1 year ago

Thanks for considering this

Jan69 commented 1 month ago

hopefully it will eventually be added in one form or another

I'm a bit rambly sqlite is great because it's got a bunch of features and it only requires a file, not a full-on server, and a LOT of stuff support it, both database tooling (viewers, editors, schema creator helpers, etc) but even down on programming language level, e.g. python has builtin sqlite module, so does php (granted they link to the official library), nodejs has an experimental sqlite module bundled in too (that needs a special flag to access it), and in cases it's not a standard(-ish) feature, there's always simple library wrappers for any language, so you can easily use it from anything, and be assured you can read it, whereas with e.g. bolt, you'd first have to basically implement a bolt driver in your preferred language to even be able to access the data properly, not to mention you'd need to do all the work of standard database stuff e.g. foreign keys, inside your app logic, basically, since the database doesn't support it (extra hard since it's key-value only, so you'd probably end up abusing the database if you want to not use a database server) sqlite is also quite robust, and can handle surprisingly high loads and data amounts with quite decent speed full-blown database servers can totally work fine, but they are almost always way overkill, for most personal/hobby projects and I somewhat doubt many people would dare to deploy an algernon app into production, on an actually high-traffic site, in the first place (where there might be actual benefits, or at least reasons to use a separate db server) if integrating a "pure" solution is too hard then just an included plugin to do that would probably also be good enough, if it's mentioned that it exists, and how to load it, in readme, but there's some go-based implementations out there, as mentioned, yeah, e.g. https://gitlab.com/cznic/sqlite and on top of that is implemented https://github.com/glebarez/go-sqlite which is "a pure-Go SQLite driver for Golang's native database/sql package", there's also interesting-looking https://github.com/ncruces/go-sqlite3 which "wraps a Wasm build of SQLite, and uses wazero as the runtime", claiming "Go, wazero and x/sys are the only runtime dependencies" however there's also a build tag for the vfs that prevents importing x/sys (which seems to be used for file locking and shared memory, which are good features, but probably not dealbreakers?) and according to wazero github, that's also written in go, and has zero dependencies, and doesn't require cgo, so miiiight be a feasible route, too, with the bonus of getting wasm execution also there's also the "cheating" option, using https://github.com/cvilsmeier/sqinn-go which depends on https://github.com/cvilsmeier/sqinn that's literally "Sqinn is an alternative to the SQLite C API. Sqinn reads requests from stdin, forwards the request to SQLite, and writes a response to stdout. It is used in programming environments that do not allow calling C API functions.", so TECHNICALLY it'd be fine (at least the go side of it only covers a subset of sqlite APIs also, though that's unlikely to be a problem) do note this is all just speculation and my uninformed opinions based on a little bit of searching around ;P
xyproto commented 1 month ago

Implemented, with the --sqlite flag. Please test.