On Mon, 01 Jul 2013 23:00:27 -0400 Igor Tandetnik <i...@tandetnik.org> wrote: > On 7/1/2013 10:33 PM, James K. Lowden wrote: > > Igor Tandetnik <i...@tandetnik.org> wrote: > >> 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. .... > > you're saying the SELECT statement may fetch any number of rows > > between 0 and 10? > > "Different process" is a key phrase here. No, the delete statement > won't be able to commit while the select statement keeps the reader > transaction open.
Thank you for clarifying that. Order is restored in my universe. ;-) > The situation would be different if a single process, while half-way > through iterating over the select statement, would issue the delete > statement. Restricting ourselves to one process, I can think of two ways that might go: 1. With two connections, one connection or the other will wait. SELECT will return 0 or 10 rows. 2. Trying to re-use a single connection to issue a second query before finalizing the first one should return an error, because the library is being improperly used. SELECT will return 0 or 10 rows, or an error. So I still don't see how the SELECT could be anything undeterministic. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
