Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Reasons not to use OPFSCoopSyncVFS ?#242

Unanswered
mzealey asked this question inQ&A
Jan 25, 2025· 2 comments· 1 reply
Discussion options

I note in#85@rhashimoto says "If I were forced to choose only one VFS for all browser applications, I would first grumble a lot and then grudgingly choose IDBBatchAtomicVFS". However this was quite some time ago and so given the downsides (size, performance, limited browser compatibility) of the async wasm builds I wonder if this would now change?

The reason I'm asking is because I'm looking at migrating from the official sqlite wasm package over to this one. My website has quite a large install base using sqlite-wasm so the jspi build is out of the question, and the async build goes very slowly. So for me sync wasm and hence OPFSCoopSyncVFS seems a very good combination. In my testing:

  • This combo is a bit quicker than the official sqlite wasm build+OPFS vfs (typically 1.1-4x speedup depending on query type)
  • Firefox is usable again - on sqlite-wasm performance was about 10* slower than chrome. Now it's about the same
  • the js/wasm comes in at half the size (700kb vs 1.2mb)
  • wa-sqlite is more compatible with modern build chains (vite)
  • No need for COOP/COEP
  • The code & docs for this project are much nicer

So, I'm looking for reasonsnot to switch to using the sync + OPFSCoopSyncVFS version compared to other VFS or compared to the official sqlite-wasm build (eg worse browser compatibility, known corruption or other unreliability, ...)

You must be logged in to vote

Replies: 2 comments 1 reply

Comment options

I note in#85@rhashimoto says "If I were forced to choose only one VFS for all browser applications, I would first grumble a lot and then grudgingly choose IDBBatchAtomicVFS". However this was quite some time ago and so given the downsides (size, performance, limited browser compatibility) of the async wasm builds I wonder if this would now change?

No, I would still say that for the same reasons. But note that the point of that entire message is that there doesn't appear to be a VFS approach that is optimal for all use cases, and so developers should pick, modify, or write a VFS that meets the needs of their application.

So, I'm looking for reasons not to switch to using the sync + OPFSCoopSyncVFS version compared to other VFS or compared to the official sqlite-wasm build (eg worse browser compatibility, known corruption or other unreliability, ...)

  • The official SQLite WASM library is backed by the SQLite project. It likely has quite a few more users, and so likely more opportunities to find and resolve bugs. It will likely have more organized continuity on the loss of a developer.
  • OPFSCoopSyncVFS doesn't support transactions involving multiple databases.
  • OPFSCoopSyncVFS isslower under contention.

There currently aren't any known issues in OPFSCoopSyncVFS. It is an out-of-the-box sort of solution, and I don't know how well exercised it has been in the real world. I am keeping my eye onthis PowerSync thread that might or might not indicate a VFS bug. UPDATE: This has been resolved and appearsnot to have been a problem with OPFSCoopSyncVFS.

Finally, let me make sure you knowthis:

Also please note that while I do strive to write production-quality code and I don't object to anyone using it in production (and they do), exploring database persistence strategies has always been the primary purpose of this project. I don't consider it a production library, and I make no commitment to solving your production issues with it.

I have a decent record of finding and fixing bugs, but past performance is no guarantee of future results. 😀

You must be logged in to vote
1 reply
@rhashimoto
Comment options

There's one little gotcha with OPFSCoopSyncVFS that I'll record here. OPFSCoopSyncVFS is filesystem transparent, which means that the database file in OPFS is a regular SQLite file that can be opened by any other SQLite program, BUT...

...If you want to open the database where it is (instead of exporting it somewhere else) - say you decide to use OPFSAdaptiveVFS instead - this will likely fail with SQLITE_CANTOPEN. The reason is that OPFSAdaptiveVFS creates some additional files in the same directory and one of them will prevent a successful open by another VFS. You can fix this by removing the file with "-wal" appended to your database filename, e.g. if your database filename is "my.db" under the root OPFS directory:

awaitnavigator.storage.getDirectory().then(d=>d.removeEntry('my.db-wal'));
Comment options

It will likely have more organized continuity on the loss of a developer.

Ha! As the Berliners say: "hope is the last thing to die!" 😜

past performance is no guarantee of future results.

It is my sincere hope to have the presence of mind to recall that quote the next time it's relevant.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
3 participants
@mzealey@rhashimoto@sgbeal
[8]ページ先頭
©2009-2025 Movatter.jp