Why does opfs-sahpool need to write 1 to the database offsets 18 and 19 when importDb()?
(1) By Spxg (uharsn) on 2025-04-18 03:46:20 [source]
The reason is that I was trying some sqlite encryption extensions. When I used opfs-sahpool to import the DB, the database was corrupted. Later I found that it was because importDB would modify the database content. I was curious about why it did this and whether I could remove it.
(2) By Nuno Cruces (ncruces) on 2025-04-18 11:50:59 in reply to 1 [link] [source]
It's trying to convert a database from WAL to rollback journal mode, because it doesn't support WAL (likely, for lack of shared memory).
(3) By Stephan Beal (stephan) on 2025-04-18 13:11:22 in reply to 2 [link] [source]
It's trying to convert a database from WAL to rollback journal mode, because it doesn't support WAL (likely, for lack of shared memory).
Initially that byte was flipped because of the lack of shared memory, but there's a different reason now:
It "does" support WAL, but only in very limited form and provides, at best, a tiny speed boost in the web environment. When opening a WAL database in WASM, because it lacks the shared memory APIs, the first action applied to the db by the client must be to switch it to exclusive-locking mode via a pragma. That's a horribly onerous requirement for users, who may or may not know that a db they've just uploaded was in WAL mode (nor should they need to know that).
The OPFS VFS goes way, way out of its way to support some degree of concurrent access via multiple tabs (something OPFS can't give us on its own), and requiring exclusive access breaks that. The OPFS SAHPool VFS "could" benefit, ever so slightly, because it only provides exclusive access, but having it retain WAL mode on imported databases would require the users to send that pragma when opening the dbs, which they shouldn't be forced to do.