4 ms·
I feel a bit stupid but I don't understand what his project does, so if someone is kind enough to ELI5 I would be grateful.
by jmnicolas 5y ago
I feel a bit stupid but I don't understand what his project does, so if someone is kind enough to ELI5 I would be grateful.
- oconnore 5y agoMy understanding: SQLite: SQL -> SQLite C query engine -> POSIX Filesystem Absurd-SQL: SQL -> (WASM) SQLite C query engine -> "filesystem" shim code -> IndexedDB
- jmnicolas 5y agoSo if I get it, he talks directly to SQLite through WASM because it's faster than IndexedDB. Why keep IndexedDB in the loop then?
- BackBlast 5y agoWhen you're running a webapp it's the primary cross-platform storage facility provided. It sounds like he's doing some buffering and bulk writes to optimize the use of indexeddb rather than just passing through each query to try to mask some of the slowness of the end storage.
- alienalp 5y agoIt is what available for persistent storage. IndexedDB run queries very slow but throughput is good enough so rather big chunks of data stored in single cell to offset latency. And IndexedDB is just one storage backend. Author says he experimented with webkitFileSystem but didn't matched IndexedDBs througput. Point of this project is storage medium abstracted so in future it will be replaced with what's better.
- rasz 5y agoIndexedDB is a dumpster fire we all got screwed over with by Mozilla after they declared "inelegant developer aesthetics" of WebSQL and killed real life usable SQL engine https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... This is how we ended with a cow shit IndexedDB nobody uses without some middle layers. This is one of those middle layers making using SQL database client side actually viable, by hiding IndexedDB as deep as possible. tldr: Mozilla's fault