> 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.
UPDATE WHERE CURRENT OF CURSOR has been part of SQL since about, oh, 1969. It has *always* been possible to update the current of cursor or to update any table or data, whether that table is being used in a current join operation, at any time while "running" the cursor (ie, calling _step()). Now then SQLite does not support the FOR UPDATE OF clause when defining a cursor (ie, doing a prepare) which is intended to inform the optimizer that updates will be issued thus and so during cursor processing and to make "such arrangements as it deems fit" to prevent programmers from doing stupid things. In fact, the FOR UPDATE OF clause was only added as a way to prevent those of limited understanding from doing things that they didn't understand yet insisted on doing anyway. Of course, if you want to add a pragma to prevent concurrent statements on a single connection, that would be fine -- provided that the default is OFF (ie, do not prevent such use -- or can be made thus when the library is compiled). Those who need extra protection to prevent themselves from shooting themselves in the head can turn it on. Those who know not to point at loaded gun at their own basal ganglia and pull the trigger have no need of the extra protection so afforded. In any case, rather serious consequences will arise by preventing multiple statements on a single connection. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
