A solution to the problem I forwarded along earlier: just move the
self._obsolete line up a few. This is a pretty critical bug, because
it's sending people's systems into an icky state.
---------- Forwarded message ----------
From: aaditya sood <aaditya@...>
Date: Dec 28, 2005 12:25 PM
Subject: [TurboGears] Re: Anyone else fighting `maximum recursion
depth exceeded' with SQLObject
Kevin Dangoor wrote:
> On 12/27/05, programmer.py <programmer.py@...> wrote:
>>The attribute lookup on self._obsolete calls self.__getattr__
>>The first statement in self.__getattr__ is a call to
>>self.assertActive has one assert statement:
>>assert not self._obsolete, "This transaction has already gone through
>>ROLLBACK; begin another transaction"
>>However, the self._obsolete in the assert calls self.__getattr__ which
>>starts the infinite recursive loop. I'm not sure of how python
>>resolves attribute lookup. But from what I can tell, there was no
>>_obsolete attribute (I did a dir(self)) at the time __del__ was called.
> __getattr__ is called when standard attribute lookup fails. As the
> other poster in this thread mentions, self._obsolete is set in the
> constructor, and I didn't see any hackery going on to get around that,
> and I didn't see anything deleting that attribute, so I'm not sure how
> we're seeing Transactions without _obsolete.
I think I found somethings.
def __init__(self, dbConnection):
self._dbConnection =3D dbConnection
self._connection =3D dbConnection.getConnection()
self.cache =3D CacheSet(cache=3DdbConnection.doCache)
self._obsolete =3D False
I figured that the init fails *before* it has had a chance to set
I moved self._obsolete =3D False to the first line, and now atleast it
doesn't go into an infinite loop. Dunno if it will screw up some
transactions rollback/commit logic though.
> I just forwarded this message on to the sqlobject list to see if
> anyone has any ideas.
Lets see if this helps. And what they say about it.
Author of the Zesty News RSS newsreader