On 2016/01/25 5:08 PM, Matthias-Christian Ott wrote: > On 25/01/16 14:14, Richard Hipp wrote: >> On 1/19/16, Meinlschmidt Stefan <Stefan.Meinlschmidt at esolutions.de> wrote: >>> Shutting down power right after a successfully committed >>> transaction rolls back that transaction on next startup. >> Patches checked in: >> >> https://www.sqlite.org/src/info/30671345b1c1ee55 >> https://www.sqlite.org/draft/compile.html#extra_durable > Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA > journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a > transaction that it said to be committed depending on the VFS? > > If so, why isn't SQLITE_EXTRA_DURABLE=1 the default? Should correctness > be more important than performance, except when the constraints are such > that correctness has to be sacrificed for performance?
I understand your concern, but don't confuse the loss of a transaction with any form of inconsistency or broken database integrity. It essentially means that on some OSes (to knowledge, only QNX currently) in the event of power loss or system breakdown right at the moment you were editing and saving some value, you might suffer the inconvenience of having to add that one song to your music list again, or have to add the name of that one contact again. This is not really an end-of-the-World-OMG-we-all-gonna-die! problem in general application terms. It's quite acceptable to 99% of databases. Sure, if your database is critical and needs the durability to be absolute, you HAVE to go full synchronous regardless of OS, but that must already be obvious at the very onset of your design and everything you do or decide must keep this in mind. Such a developer would never simply roll with the defaults of any DB system - I'd hope. The very idea of defaults is to cater for the majority, not the rarest of use-cases.
