On Nov 2, 2010, at 5:15 PM, Torsten Landschoff wrote:

>> In addition, isolation_level=None with pysqlite disables the DBAPIs entire 
>> transactional system.  SQLAlchemy relies upon this system to handle proper 
>> transactional behavior.  Per their documentation, some statements will fail 
>> if executed in a transaction - SQLAlchemy does not want to be involved in 
>> reorganizing how the DBAPI wants to approach things, emitting manual 'begin' 
>> and 'commit' strings, etc.
> 
> Reading the pysqlite source, all that this magic isolation_level setting
> does is to emit an begin statement in front of UPDATE, DELETE, INSERT
> and REPLACE commands. And implicitly commit whenever any other
> non-select statement is executed (which includes SAVEPOINT commands!).
> 
> I don't think it makes a huge difference for SQLAlchemy to rely on this
> insertion of "begin" statements.
> 
> References:
> 
> Emitting begin (via _pysqlite_connection_begin):
> http://code.google.com/p/pysqlite/source/browse/src/cursor.c?r=2.6.0#598
> 
> That's the only invocation to _pysqlite_connection_begin. After reading
> a bit more, I can see your point. Setting isolation_level to None
> actually disables the commit and rollback methods on cursor objects.
> Whee!

we get occasional requests to work around Pysqlite's bugs regarding 
transactional behavior, since they seem to be extremely slow in fixing them.   
I'm very uncomfortable bypassing normal DBAPI behavior by default, but I would 
support a flag in 0.7 to the pysqlite dialect "manual_transactions" which sets 
isolation_level=None, emits "BEGIN", "ROLLBACK", "COMMIT".   That way users who 
insist on doing it this way are the only ones exposed to unforeseen issues, and 
they can contribute tests and patches to make it work better.   Some initial 
testing showed that it definitely had issues,  so it remains to be seen how 
much of an impact this has.   As we come across new caveats with this "manual" 
mode and add further adjustments, we would in effect be reimplementing 
pysqlite's own feature.


> 
> 
>> So I consider this a pysqlite bug, and they should offer a mode by which 
>> there is no implicit commit for CREATE TABLE.
>> 
>> See http://docs.python.org/library/sqlite3.html#controlling-transactions 
> 
> Agreed.
> 
> Greetings, Torsten
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to