On Thu, 4 Jul 2013 20:36:10 +0100 Simon Slavin <slav...@bigfraud.org> wrote:
> On 4 Jul 2013, at 8:15pm, James K. Lowden <jklow...@schemamania.org> > wrote: > > > It doesn't usually matter, right? The fact that the atomic SELECT > > is spread out across N function calls is irrelevant if they are > > executed in uninterrupted sequence, because other connections are > > blocked from modifying the affected tables until the SELECT is > > finalized. > > Right. The supported, cannonical, predictable, deterministic way to > use _prepare() is to get all the way from _prepare() to _finalize() > without doing anything but use that statement. And if you do that it > doesn?t matter precisely which call does the lock and which one does > the unlock. Thank you for the clarification, Simon. > In real life SQLite allows many other things to happen. But > predicting what happens then requires a detailed understanding of > SQLite. In real life, programs are complex, and libraries are misused (intentionally or not). SQLite's job is to be a DBMS: to provide predictable, safe access to the database, defending against errors foreign and domestic (i.e. hardware errors, OS errors, *and* user errors). To permit corrupted data to arrive in the application while a SELECT statement is being evaluated is to abrogate its most basic promise. CS theory tells us that simple interfaces help control complexity. An interface that "requires a detailed understanding of the [internals]" is not simple; in effect the entire SQLite codebase becomes "the interface". And an undocumented one at that. One practical effect of complexity is confusion and error. Which is exactly what happened in real life: the OP was surprised that an application logic error resulted in nondeterministic *library* behavior. As well he and thousands like him should be and will be as long as the situation stands. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
