Comment by ori_b
5 years ago
> Are you talking about a server application?
I'm talking about doing a handful of transactions -- even a single one, now that I looked at the actual numbers that sqlite discusses -- being enough to introduce user-visible jank.
> Never heard that SQLite has unsafe operations. Any source?
The sqlite docs. You can improve the performance of sqlite by multiple orders of magnitude by messing with things like https://www.sqlite.org/pragma.html#pragma_synchronous, at the cost of safe atomic updates.
> The sqlite docs. You can improve the performance of sqlite by multiple orders of magnitude by messing with things like https://www.sqlite.org/pragma.html#pragma_synchronous, at the cost of safe atomic updates.
Thanks for the link, but only when the OS or your computer crashes, not even the application itself. Could you introduce any application file format that is safe in that case? Obviously your JSON file format is much more unsafe than that, not to mention the huge overhead of JSON with binary data.
> Thanks for the link, but only when the OS or your computer crashes, not even the application itself.
Ah, right there are also the journalling knobs that you'd tweak to get to max performance -- either in-memory or no journalling at all make a big impact. There are a bunch of them scattered throughout the docs.
> Could you introduce any application file format that is safe in that case? Obviously your JSON file format is much more unsafe than that, not to mention the huge overhead of JSON with binary data.
Yes, any format is safe if you write to a temporary file, and then rename(2) it to replace it. This is guaranteed to be atomic, so it works with anything (including sqlite, though at that point all sqlite does is cost you performance and complexity).