On 07.07.2010 14:20, Benoit Chesneau wrote:
On Wed, Jul 7, 2010 at 1:40 PM, Jan Lehnardt<j...@apache.org> wrote:
On 7 Jul 2010, at 08:31, Benoit Chesneau wrote:
I dislike to have too much options though.
@damien
I don't understand this "keep it for 1.0" mantra. Since it's more a
"philosophical" change than a technical one, I would prefer that
change on 1.0 whatever this number means. How do people use CouchDB
in production ? Is delayed_commit turned off most of the time ?
I am with Damien, all other releases ship with the current default setting.
Changing it *a day* before 1.0 does not sound like the way to go.
right, it may be too late to do that now.
Anyway rereading the doc we provide, I think delayed_commit don't
break the promise since db is always in consistent state.
But we may need like you said, to clarify some docs imo and maybe give
to users some tricks to help them to flush to disk before any machine
shutdown or such ?
About the use on laptop and co, laptops are likely less stable than
server machines, and we tend to shutdown them more often too. With
delayed_commit=True, when someone shutdown his laptop and forget to
apply delayed commit (and most of the time, if we don't automatize
that, I bet he will), data in memory will be lost.
I remember two instances of data loss with CouchDB 0.7 on Mac OS X
when Erlang wasn't using the fully reliable FULLFSYNC option to flush
data to disk (which is btw more reliable than on any other system). After
we patched Erlang to do the right thing on Mac OS X, I haven't heard
of a single instance of data loss on a laptop or anywhere else.
There was a recent discussion about couchdb shutdown that was raised
by this default settings. In my case I never lost data but just
because I set couchdb as the last to shutdown.
As a user of openbsd, one of the reasons I use this system (except
its simplicity) is that it is secured by default on the contrary most
linuxes/bsds aren't. Most of the openbsd users know that security will
impact performances. I think I would prefer to have a completly safe
couchdb even if performances decreased.
This brings up an interesting point: we ship the CouchDB source.
Most users use CouchDB through some distribution (apt-get, rpm,
CouchDBX etc.). The distributors should decide for their users which
setting is best.
That's indeed a way to handle that, this is again a doc problem I guess.
Again, I'd like to keep the default we had forever and commence
with the release of 1.0.
for both reasons here, you have my +1 :)
- benoit
Good points everyone. Here's my +1 for keeping the current default.
I'd say, I've opened the case, now I close the case.
Cheers,
Volker
