On Sat, 13 Jul 2013 00:09:36 -0600 "Keith Medcalf" <kmedc...@dessus.com> wrote:
> UPDATE WHERE CURRENT OF CURSOR has been part of SQL since about, oh, > 1969. (I assume that's dramatic license.) > 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. FOR UPDATE OF does more than pass a hint to the optimizer. It changes the semantics of the cursor from read-only to read-write. Other than the clumsy syntax, I don't see how it has anything to do with stupid. > 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. It seems we differ on what constitutes a good API, and on the value of simplicity. Complexity is evil. Every change in behavior is another state to master, doubling the potential states, adding to complexity, making the interface harder to understand and use correctly. The goal of the library design is to find the narrowest path through which the information can pass, limiting the number of functions and states and therefore the number of potential errors (on both sides of the API) for a given functionality. Now, it's a fact most programmers don't consider "a little more complexity" a problem, and you would seem to be in that group. It's also a fact that 90% of programmers consider themselves above average, so we know there are problems with our self-assement, in aggregate. In case you don't think modifying a table using the same connection that is currently processing a SELECT adds to the complexity of the SQLIte API, I refer to you this very thread. I'm an experienced SQLite programmer, and because I hadn't ever been tempted to try that particular trick, I hadn't ever imagined it would work (or not work, depending on your perspective). It took several exchanges to describe the behavior, eventually prompting Dr. Richard to draft an additional 731 words of documentation. Even at that, questions remain about exactly how it behaves, and about which behavior is semantic and intentional, and which is incidental. Simplicity is intrinsically valuable for everyone, not merely the stupid. You yourself, a manifestly intelligent being, learned today that "order by +rowid" changes the behavior. Yet nothing about ORDER BY (much less "+") suggests a change in isolation semantics. It's just a queer tick that happens to work, like the queer tick of using a cross join to affect the query optimizer. They represent what is known as "accidental complexity". They should be rectified, not venerated. That's an observation, by the way, not a demand. The only software that can't be improved is already perfect. I haven't come across that particular gem yet, so I know SQLite has a lot of company. I'm faintly surprised I had to make this argument. To me it's self-evident that complexity to be avoided, and that weird behavior is complex almost by definition. To me it's axiomatic that a library promising transaction isolation shouldn't break that promise under any circumstances. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
