←back to thread

Sqlite3 WebAssembly

(sqlite.org)
506 points whatever3 | 6 comments | | HN request time: 0s | source | bottom
1. catapart ◴[] No.41852302[source]
I wasn't able to tell from a quick look through the page: could someone help me understand the use cases here?

More specifically, would this be able to be a "replacement" for indexedDB? Does the data persist, or do I need to keep the sqlite file in the filesytemAPI (or indexedDB/localstorage) myself?

replies(1): >>41852717 #
2. azangru ◴[] No.41852717[source]
From the about page:

> Specific Goals of this Project

> Insofar as possible, support persistent client-side storage using available JS APIs. As of this writing, that includes the Origin-Private FileSystem (OPFS) and (very limited) storage via the window.localStorage and window.sessionStorage backend.

replies(1): >>41852866 #
3. catapart ◴[] No.41852866[source]
Right but, to my eyes, that's vague?

What I'm asking is if I need to manage the sqlite file, as I would on an OS's file system, or if accessing the sqlite library will automatically persist that data to those web-native storages, like the way indexedDB doesn't require me to load an "idb" file and then "save" or "commit" that save. I just access it and write.

To be clear: I'm not asking academically. I wrote a whole library for managing data in indexedDB for local-first apps, and while it works well enough for what I need, it's iDB so it's subject to data deletion (not common, but allowed in the spec if necessary), and it's a pain to work with just because of its nature and API. So I've been waiting to move to sqlite for a while with the only holdbacks being "is it too heavy?", and "how much has to change?". With WASM, I think we're about as lightweight as its going to get. So I'm just curious if this aims to be a drop-in replacement, or if it still expects you to use it like sqlite on a native platform.

replies(1): >>41854779 #
4. sgbeal ◴[] No.41854779{3}[source]
> Right but, to my eyes, that's vague?

We (the sqlite project, where the "vague" description comes from) do not define the use cases. Similarly, in the docs for the C library you won't find any more than passing references to specific use cases, and those are typically contrived for the sake of example. (One notable exception: <https://sqlite.org/appfileformat.html>)

> What I'm asking is if I need to manage the sqlite file, as I would on an OS's file system, or if accessing the sqlite library will automatically persist that data to those web-native storages, like the way indexedDB doesn't require me to load an "idb" file and then "save" or "commit" that save. I just access it and write.

That's all covered in the docs (of which there are well more than 100 lovingly-hand-written pages), but the short answer is "it just works." You have the _option_ of importing and exporting databases from the browser-native storage, but you don't have to.

For starters, see: <https://sqlite.org/wasm/doc/tip/persistence.md>

replies(1): >>41856142 #
5. asdfman123 ◴[] No.41856142{4}[source]
> do not define the use cases

I genuinely don't mean to sound rude, and maybe I misunderstand, but how do you build software if you're not doing it with use cases in mind?

replies(1): >>41856418 #
6. manmal ◴[] No.41856418{5}[source]
Usage is laid out well in the docs, I‘m not sure GP has read them. IMO it’s obvious that many use cases have been kept in mind. Defining a use case != accommodating a use case