exceptions.AttributeError: "'pysqlite2.dbapi2.Connection' object has no attribute 'autocommit'"

Somebody please forward this to the SQLObject people:

This happens because in SQLObject's sqlite/dbconnection.py in the method _setAutoCommit() the check "if using_sqlite2" fails even though this global variable should be set at this point. But for some reason, it isn't, so the code path that was intended for pysqlite 1.x is executed against a pysqlite 2.x Connection object and fails.

I believe it does happen when there is an error during model creation, and SQLObject tries to roll back. Minimal model to reproduce:

from sqlobject import *
from turbogears.database import PackageHub

hub = PackageHub("test")
__connection__ = hub

class Foo(SQLObject):
    bar = MultipleJoin("Bar")

I got to the same conclusion but I didn't find the problem (I have never look at SQLOBject code so I had no idea where to look for it)

I should also note that this happens on a RelatedJoin? also. This is the model I try I start getting the error ones I added the RelatedJoin? to B

from sqlobject import * from turbogears.database import PackageHub?

hub = PackageHub?("wiki20") connection = hub

class Page(SQLObject):

pagename=StringCol?(alternateID=True, length=30) data=StringCol?()

class B(SQLObject):

number=IntCol?() a=RelatedJoin?('Page')

Just a note-

The new Widgets tutorial:

http://trac.turbogears.org/turbogears/wiki/IntroductionToWidgets

will cause this error on mac osx 10.4.5 / mac python 2.4.1 / tg 0.9a4 , and sqlite from cheesehop

It seems that the real problem is buried deep inside TurboGears and results from a lot of magic that gets out of hands:

- the exception is raised because a Transaction object gets garbage-collected - the transaction object is stored in a thread-local variable - at the time the Transaction is garbage-collected, other things it depends on have already been collected => ERROR

This could be fixed if the transaction object is reset at an appropriate point in time. For this to happen, I think the AutoConnect/PackageHub? must get an additional method to reset its connections/transactions.

This could be fired when a special function in the model module has been called.

a work around to this is to disable transactions in sqlite.

sqlobject.dburi="notrans_sqlite:///file_name_and_path"

taken from http://tinyurl.com/oy42j

Seems something similar happens with pysqlite 1.x too - different exception:

Exception exceptions.AttributeError?: "'NoneType?' object has no attribute 'releaseConnection'" in <bound method Transaction.del of <sqlobject.dbconnection.Transaction object at 0x409fc24c>> ignored

but looks similar and the notrans_ workaround works here too.

I've stumbled on this problem as well. I've tried the workaround suggested in the mailing list thread but it doesn't seem to be working for me. However the workaround suggested in #279 (using soClasses to define the order in which tables are created) does work for me.

This ticket has been active for a while, any updates? I got the book Rapid Web applicatiosn with Turbogears and am more or less stuck since in chapter 5 I keep getting this error!

sadly this is one of those things noone knows why is it happening.

I'm pretty much brand new to TurboGears, and trying to follow this tutorial: http://exogen.case.edu/turbogears.html

I'm getting this error on the first tg-admin sql create.

I previously worked through the beginning of the wiki tutorial, and I did not have this problem.

I've got Python 2.4.3, sqlite 3.3.5, and pysqlite 2.3.1, on Gentoo.

Batch moved into unclassified from 1.1 to properly track progress on the later

I've added

print using_sqlite2

at several places in sqlite/sqliteconnection.py. Here is the output:

True True ... None

If I replace the "if using_sqlite2:" in _setAutoCommit() with "if True:", then I get the NoneType? error from comment 06/12/06. This is caused from calling

DBAPI.releaseConnection(self, conn, explicit=explicit)

in _setAutoCommit() because DBAPI is None.

I have the feeling that this happens because a lot of objects are already garbare collected when releaseConnection() is called. This would also explain why it's a flacky error.

I could fix the problem with this change at the top of releaseConnection (thirdparty/sqlobject/sqlobject/sqlite/sqliteconnection.py:144):

if self._memory or DBAPI is None:

return

(I added a check to return if DBAPI is None).

My system: SuSE 10.2, Python 2.5, TG 1.0.2 from SVN, SQLObject 0.8.

Sorry, just saw a typo. The call trace is:

Transaction.__del__ (dbconnection.py:913)
Transaction.rollback (dbconnection.py:872)
Transaction._makeObsolete (dbconnection.py:896)
SQLiteConnection._setAutoCommit (sqliteconnection.py:~167) <-- Crash #1 here
SQLiteConnection.releaseConnection (sqliteconnection.py:~152) <-- Crash #2 here

makeObsolete() makes the two last calls (and not _setAutoCommit() as I wrote above). The line numbers in sqliteconnection.py are off a bit because I've sprinkled the code with debug print's :-)

If you add: joinColumn="parent_table_id_column" to the MultipleJoin? statement the exception disappears.

e.g.

class Foo(SQLObject):

bar = MultipleJoin?("Bar", joinColumn="foo_id")

Maybe but that doesn't solve the root cause of the problem. It just hides it.