On May 18, 2009, at 1:13 PM, John Elrick wrote: > John Elrick wrote: >> SNIP >> >>>> I say this because your example implies that the Python wrapper >>>> starts >>>> the transaction automatically inside the execute, and I would not >>>> be >>>> surprised if it did so BEFORE executing the SQL parameter. >>>> >>>> >>> The cursor() method that I call on the conn for the SELECT should >>> give >>> me a separate transaction. >>> >> >> Are you certain the wrapper is behaving that way? As an experiment I >> altered my Ruby example to try to force it to go into an endless loop >> and failed (see below). My experiments seem to confirm that Sqlite >> is >> behaving as you expect, perhaps it is the wrapper which is not? >> > > Attempting this closer to the metal, it appears I was mistaken. A > select from outside a transaction does indeed have visibility to rows > added inside the transaction. I would not have expected this > either, Yang.
Double-check your findings, please John. The changes within an SQLite transaction are not visible to other database connections until the transaction commits. (However, they are visible within the same database connection.) An exception to the previous paragraph is if you are using shared cache mode and you do a PRAGMA read_uncommitted=ON; D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
