On 7/12/2013 12:30 PM, James K. Lowden wrote:
On Mon, 08 Jul 2013 00:37:55 -0400
Igor Tandetnik <i...@tandetnik.org> wrote:
I don't believe it's SQLite's job to ensure the programmer doesn't
shoot herself in the foot. After all, you don't expect, say, the C++
compiler to prevent you from destroying an object while another part
of the program holds a pointer to it. This SQLite's behavior is little
different.
Au contraire, mon ami: it is very much SQLite's job to prevent logical
programming errors from corrupting the data.
Define "the data". The database file remains perfectly intact, no
corruption there. Your internal state might be corrupted - but how is
this SQLite's problem?
The analogy to C++ is inapt. C++ makes very few guarantees about an
object's lifetime. That is its design and definition.
I'm not sure I understand this claim. C++ provides certain guarantees
about object lifetime. SQLite provides certain guarantees about its
behavior. Is there a particular number of guarantees that must be
provided, below which the set of guarantees would be reasonably
described as "very few"? Is C++ below this threshold, and SQLite above it?
SQLite OTOH is
a DBMS. If used in a way that could cause it to return unreliable
results, its only alternative is to return an error.
Correct. So between the action of returning unreliable results, and the
only alternative action of returning an error, SQLite authors chose the
former. For good reasons, too.
More apt would be if open(2), called with O_EXLOCK twice on the
same file, were to permit the second process to modify the file
as the first one reads it.
No, the case here is that the same process, in the middle of reading
from a file, writes to that same file through the same handle,
overwriting the data it is just about to read. Again - we are not
talking about two transactions interfering with each other - that works
the way you expect. We are talking about a single transaction modifying
the data it itself is reading.
In fact, I'd be interested if you could
point to a single standard C library function that, when called
out-of-sequence, doesn't return an error but permits the process to
proceed destructively.
You got to be kidding me. C++ language and library are chock full of
conditions that trigger undefined behavior. E.g. calling free() twice on
the same pointer (as Drake Wilson notes), or fclose() twice on the same
FILE* handle.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
