On Mon, Jan 25, 2016 at 10:08 AM, Matthias-Christian Ott <ott at mirix.org> wrote:
> > 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 wouldn't want that, as that would entirely depend on the application. Maybe I'm an edge case, but I've written apps where the database is 'production', but not 'valuable' enough to have performance slapped. The app didn't care if the data was destroyed. It'd go and recompile what it needed from the external sources from which the now-destroyed database was created on. It basically was a cache type implementation, but changes to the database then were pushed to whatever the external source was. SQLite is also mostly looking at devices that are embeded, limited on performance, and not a lot of wiggle room where performance would seriously degrade the "worth-while-ness" of the device. ... which is why I no longer have a Rogers PVR as it'd take 5+ seconds to do anything...ahem... Anyways.. You also have to look at balance across many millions (or is it billions?) of devices out there that use SQLite for their primary operations. Slapping a serious performance decrease on devices where time and performance is essential BY DEFAULT seems a little strict. And all at the cost of one transaction? To some, maybe a worthwhile trade off, sure, but I'm not sure I'm be overly outraged if my wifes music box (iPod) suddenly had to recompile its music list.
