Or users could simply get confused about what to do with those files and contact support a million times just to ask why these files exist, whether they need to be copied as well, why they are getting large, etc.
These issues can be worked around, but I wonder how many apps that use SQLite actually bother doing that. Clearly not all of them [2].
Avoiding file corruption is non-trivial regardless of file format, but giving users additional ways to corrupt their data is never a good thing.
So I think for small, user visible application files that don't need any database functionality, the onus is still on engineers to justify their choice of SQLite.
[1] https://www.sqlite.org/howtocorrupt.html
[2] https://forum.audacityteam.org/t/aup3-wal-file-remains-and-l...
This reminds me of a college roommate who was dissatisfied with his computer, likely due to malware from sketchy sites. He decided to delete large or suspicious files from window’s system32 folder. By suspicious I mean he didn’t like the file name.
He had to get a new computer later in the semester.
I had actually meant JOURNAL_MODE=DELETE, though. This would not technically use a WAL file, though there would be a rollback journal file that exists only for the duration of the transaction.
The usual way to deal with this is to write to a temporary file and then atomically replace the original file with that temporary file. You could do the same thing with an SQLite database. This is the workaround I was referring to earlier.
journal_mode=delete may not be the worst compromise, but I hate the idea of exposing users to potential database corruption, even in a relatively unlikely event.
I’m surprised it would corrupt the database. The database could have included a unique identifier as well as in the journal and refuse opening the database if the identifiers don’t match.
That’s one hell of an endorsement.
That argument implies that we're stuck with the browser's single built-in home page because every other web page has to be downloaded.
How is having to download sqlite3.wasm any different from having to download HTML, CSS, JS, images, etc.?
'unnecessary' file size. K matter on the web still.
I'm not normally a web guy, but from https://sqlite.org/download.html it looks like it's ~800k extra added to initial page load? Based on average mobile speed in US of 97.09Mbps; that's an extra half second added to initial page load. That's not trivial; maybe an extra 15% bounce rate on initial hits.
If you're serving it uncompressed, which no production-grade site will (for a given definition of "no"/"none").
> K matter on the web still.
Not, i opine, for the types of apps which want to host client-side databases. These are client-side applications, not "web pages."
Even a bare-bones, database-less google.com is now 3.14mb uncompressed (1.32 compressed), and that's not counting the pieces which uBlock Origin keep from loading. It loads somewhere around 2MB (uncompressed) of JS.
Last i checked, gdrive downloaded some 14mb to get up and running.
> that's an extra half second added to initial page load. That's not trivial;
We'll have to agree to disagree on whether half a second extra initial-hit-only load time is trivial.
That 847 KB is actually the size of the (compressed) zip file, but it does contain other files. The compressed WASM + the JS to load it is probably about 500K, depending on the specifics of compression & minification.
How things change.
Unless you had a 3KHz processor (and no processor ever had that), that statement is just not true.
From memory the wasm binary of wa-sqlite is ~1mb, which is certainly not nothing but is an acceptable one-time download size for many web apps. I've seen websites with single image files larger than that. Not an advocating for more bloated web apps, but a sqlite download might not be a deal breaker.
If the user could benefit from either of those, atomically updated plain files are great. Otherwise, SQLite is perfect.
Of course there's always workarounds to use SQLite in memory and dump to SQL code and such.
https://www.sqlite.org/famous.html