QUESTION 1: The default setting in version 2.8 is ON. For version 3.0 we propose to change the default synchronous setting to FULL. Does anybody have any problems with this?
No problem. In fact, I would recommend the change to FULL regardless of whether that was being planned or not.
As a general rule, I always advocate default settings which are the most effective at safe data preservation. Even if things are slower as a result, data integrity is the most important thing. Any settings that allow for less safety should be explicitely enabled by a user that knows full well the consequences of what they are doing, and are willing to take the risks for extra speed. And for people who don't know enough to judge whether they should take risks, they should be handed the safest option by default. Naive users have to be able to trust that defaults are in most peoples' best interest.
And in this case, as you said, there is little perceivable difference between ON and FULL, so considering you are already using ON, FULL is a small price to pay.
QUESTION 2: We propose to eliminate default_synchronous and have the regular synchronous pragma change the synchronous setting persistently. Does anybody have any problems with this?
I suggest that you keep both options. As Derrell said, for API consistency.
Alternately, I have a different suggestion. Perhaps default_synchronous could simply always be FULL and that default isn't changeable. Anyone who wants to change it will always do so on a non-persistent basis.
This is advantageous when, for example, multiple people are sharing a SQLite data file. Subsequent users can always trust that the file is set to its safest mode by default, regardless of how the previous users worked with the file.
And even for those people who want a faster setting for some circumstance, it is little extra work to request that each time. If code is opening the database, that's one extra line. If its manual such as with the command line client, then people are unlikely to use said client very often in a non-synchronous way.
That's what I think.
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
