From d19f9312d3267770f975c4c45f45f1e7e45ba26e Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Thu, 17 Apr 2025 16:11:47 -0300 Subject: src/content/blog/2020/08/31/database-i-wish-i-had.adoc: Recover longform footnote --- .../blog/2020/08/31/database-i-wish-i-had.adoc | 42 +++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) (limited to 'src/content') diff --git a/src/content/blog/2020/08/31/database-i-wish-i-had.adoc b/src/content/blog/2020/08/31/database-i-wish-i-had.adoc index a22e9ea..7f010b9 100644 --- a/src/content/blog/2020/08/31/database-i-wish-i-had.adoc +++ b/src/content/blog/2020/08/31/database-i-wish-i-had.adoc @@ -53,6 +53,7 @@ Let's go over what I mean by each of those aspects one by one. :pouchdb-adapters: https://pouchdb.com/adapters.html :datomic-storage-services: https://docs.datomic.com/on-prem/storage.html :sqlite-amalgamation: https://www.sqlite.org/amalgamation.html +:pointed-out: https://news.ycombinator.com/item?id=24338881 I think the server-side database landscape is diverse and mature enough for my needs (even though I end up choosing SQLite most of the time), and what I'm @@ -67,7 +68,46 @@ the source of truth, and allow the application to work on top of it. database that runs {sqlite-whentouse}[almost anywhere]. What I miss from it that SQLite doesn't provide is the ability to run it on the browser: even though you could compile it to WebAssembly, [line-through]#it assumes a POSIX -filesystem that would have to be emulated#[multiblock footnote omitted FIXME]. +filesystem that would have to be +emulated#{empty}footnote:posix-sqlite[ + It was {pointed-out}[pointed out to me] that SQLite doesn't assume the + existence of a POSIX filesystem, as I wrongly stated. Thanks for the + correction. +pass:[

] + This makes me consider it as a storage backend all by itself. I initially + considered having an SQLite storage backend as one implementation of the POSIX + filesystem storage API that I mentioned. My goal was to rely on it so I could + validate the correctness of the actual implementation, given SQLite's + robustness. +pass:[

] + However it may even better to just use SQLite, and get an ACID backend without + recreating a big part of SQLite from scratch. In fact, both Datomic and + PouchDB didn't create an storage backend for themselves, they just plugged on + what already existed and already worked. I'm beginning to think that it would + be wiser to just do the same, and drop entirely the from scratch + implementation that I mentioned. +pass:[

] + That's not to say that adding an IndexedDB compatibility layer to SQLite would + be enough to make it fit the other requirements I mention on this page. SQLite + still is an implementation of a update-in-place, SQL, table-oriented database. + It is probably true that cherry-picking the relevant parts of SQLite (like + storage access, consistency, crash recovery, parser generator, *etc.*) and + leaving out the unwanted parts (SQL, tables, threading, *etc.*) would be + better than including the full SQLite stack, that's simply an optimization. + Both could even coexist, if desired. +pass:[

] + SQLite would have to be treated similarly to how Datomic treats SQL databases: + instead of having a table for each entities, spread attributes over the + tables, *etc.*, it treats SQL databases as a key-value storage so it doesn't + have to re-implement interacting with the disk that other databases do well. +pass:[

] + The tables would contain blocks of binary data, so there isn't a difference on + how the SQLite storage backend behaves and how the IndexedDB storage backend + behaves, much like how Datomic works the same regardless of the storage + backend, same for PouchDB. +pass:[

] + I welcome corrections on what I said above, too. +]. {pouchdb}[*PouchDB*] is another great example: it's a full reimplementation of {couchdb}[CouchDB] that targets JavaScript environments, mainly the browser and -- cgit v1.2.3