On 7/8/2013 12:09 AM, James K. Lowden wrote:
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.
For SQLite, the "user" is the programmer integrating SQLite library into her application, not the end user of that application. 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.
CS theory tells us that simple interfaces help control complexity.
... but simplicity has to be balanced against functionality. A library that does nothing at all is very simple, but also very useless. CS practice tells us that there are trade-offs to be made.
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.
The documented behavior is - if you modify the data as you iterate over that same data, the results are unpredictable. So don't do that, and then you won't need detailed understanding of SQLite internals.
-- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
