On 2 Jul 2013, at 3:33am, James K. Lowden <jklow...@schemamania.org> wrote:
> Igor Tandetnik <i...@tandetnik.org> wrote: > >> On 6/30/2013 11:13 PM, Igor Korot wrote: >>> Well I will use another statement variable as in the sample code. >>> My questions was: if I call delete on the record that was just >>> retrieved in another query will this delete affects it? >> >> If you change data that a live SELECT statement is iterating over, >> the outcome is unpredictable. It may appear to work, it may skip >> rows, it may return some rows more than once > > Really? That's not what SERIALIZABLE means. > > If I have 10-row table T and issue > > select * from T; > > and from a different process issue > > delete * from T; > > you're saying the SELECT statement may fetch any number of rows > between 0 and 10? No. The SELECT statement is fine and consistent. But the SELECT statement is all of _prepare(), _step(), and _finalize(). Igor is pointing out that that if you stop before _step() has returned SQLITE_DONE then you haven’t /done/ a SELECT statement, you’ve just started one and it is still, in his word, "live". On 2 Jul 2013, at 4:30am, James K. Lowden <jklow...@schemamania.org> wrote: > So I still don't see how the SELECT could be anything undeterministic. SELECT is deterministic. You want to know what it does, read the source code and understand the file system protocols it uses. But it’s not predictable in any simple way because its behaviour changes depending on lots of things like whether there’s a covering index, and what other threads do things with the database and when. So you can't write a simple set of rules that it’ll always follow: it does different things under different circumstances. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
