On Fri, 12 Jul 2013 14:25:36 -0400 Igor Tandetnik <i...@tandetnik.org> wrote:
> >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? ... > > 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. It's not SQLite's "problem", I suppose. If it works as intended, it's not a bug. Where we disagree is over whether that intention best serves the application programmer. You think it's OK: he made his bed and now he can lie in it. Modify the table you haven't finished selecting, and prepare to see your application melt. I think it's not OK: The library is in a position to prevent data corruption in the application, yet does not. An error returned by the library would prevent errors stemming from very strange behavior while processing the SELECT. (I think we agree the behavior is strange.) As you pointed out, it's a kind of compromise: Because SQLite locks the file, if the same handle cannot be used for more than one statement at a time, the application would have to use the database in a strictly serial fashion. And I can understand the appeal of the simplicity of One Big Lock. I would like to see a way to permit multiplexed use of the handle while preventing "undefined behavior". I hope you agree that would be an improvement. It would simplify the API and eliminate 731 words of documentation. The simplest suggestion I can make is a per-connection trivial table "lock". The set of tables being selected at any one time is known. Certainly it's not complex to know whether a table is the target of INSERT, UPDATE, or DELETE and is in the set of those being SELECTed. Return an error if any attempt is made to modify those tables. Continue to rely on filesystem semantics when more than one connection handle is involved. That change would remove uncertainty about the effects of updating the database while SELECT is in progress. Because the combination of shared_cache & read_uncommitted have same (nonisolation) property, that configuration would become more useful, too. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
