sqlite savepoint problem
Laszlo Nagy
gandalf at shopzeus.com
Fri Mar 12 02:32:21 EST 2010
> From memory you can't issue a "CREATE TABLE" statement inside a
> transaction, at least not at the default isolation level. Such a
> statement will automatically commit the current transaction. Doesn't
> help with your current problem but worth pointing out :-)
>
Thank you. I'll keep in mind.
> When debugging strange transaction behaviour, I find it easiest to
> create the connection with isolation_level=None so that are no implicit
> transactions being created behind your back. Not sure why, but setting
> this makes your example work for me.
>
Yes, same for me. But setting it to None means auto commit mode! See here:
http://docs.python.org/library/sqlite3.html#sqlite3-controlling-transactions
But it does not work that way. Look at this example
import sqlite3
conn = sqlite3.connect(':memory:')
conn.isolation_level = None
with conn:
conn.execute("create table a ( i integer ) ")
with conn:
conn.execute("insert into a values (1)")
conn.execute("SAVEPOINT sp1")
conn.execute("insert into a values (2)")
conn.execute("SAVEPOINT sp2")
conn.execute("insert into a values (3)")
conn.execute("ROLLBACK TO sp2")
conn.execute("insert into a values (4)")
conn.execute("RELEASE sp1")
with conn:
for row in conn.execute("select * from a"):
print row
It prints:
(1,)
(2,)
(4,)
So everything is working. Nothing is auto commited. But if I change it
to "DEFERRED" or "IMMEDIATE" or "EXCLUSIVE" then it won't work. Why?
I'm now confused. Also, I could not find anything about these isolation
levels on the sqlite website. The only think I could find is "PRAGMA
read_uncommited". If that is the same as setting isolation_level to
None, then I don't want it.
L
More information about the Python-list
mailing list