On Thu, 12 Mar 2009 at 20:25, Antoine Pitrou wrote:
R. David Murray <rdmurray <at> bitdance.com> writes:
By the way, I would not like to see python programmers encouraged to make
the same mistake that sqlite3 made. The decision about how aggressive
to be on flushing data to disk should be in the hands of the _user_, not
the application.
I disagree. The user usually does not know which kind of flushing is needed in
order for his data to be safe. Actually, he probably doesn't even know what
flushing means, and that files are ever "closed".
Let me try some examples.
Suppose I'm running my applications on a laptop and I don't want the
disk to be spinning continually while I work. I'm willing to take the
risk of data loss in order to extend my battery life.
And then there's the high performance server situation, where all the
hardware is at least double redundancy, and we want the fastest disk
performance possible, with data reliability being taken care of by
the redundancy in the system. (Is this actually possible with today's
hardware and software? I don't know, but it _should_ be.)
In between there is the medium to low performance, non-redundant server,
where we are willing to trade performance for data integrity.
In all three of these situations I might be running the exact same
application software.
So, the user needs to be in control. Of course, for users who don't
understand the tradeoffs, there should be a sane default.
Oh, and the user doesn't need to understand flushing, they just
need to be in control of the performance versus data-integrity-
in-the-face-of-crashes tradeoff.
--
R. David Murray http://www.bitdance.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
