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