On 7/1/2013 10:33 PM, James K. Lowden wrote:
On Sun, 30 Jun 2013 23:27:23 -0400
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.
SERIALIZABLE is a transaction isolation level. It applies to interaction
between two transactions on two separate connections. It is perfectly
normal and expected for a single transaction to be affected by changes
it itself makes.
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?
"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.
The situation would be different if a single process, while half-way
through iterating over the select statement, would issue the delete
statement. This is roughly similar to what the OP is trying to do, as
far as I can tell.
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
