src/content/blog/2020/08/31/database-i-wish-i-had.adoc: Recover longform footnote

1 files changed, 41 insertions, 1 deletions

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:[</p><p>]
+  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:[</p><p>]
+  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:[</p><p>]
+  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:[</p><p>]
+  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:[</p><p>]
+  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:[</p><p>]
+  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