On Thu, May 03, 2007 at 04:01:04PM -0500, Sidnei da Silva wrote:
> Alright, here it is.
Thank you!
> Now that I look at it, iterSelect() is indeed in
> the backtrace, but the assignment is in _init, which means it's when
> the object instance is created.
But assignment to ._connection coul
On 5/3/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Thu, May 03, 2007 at 03:20:42PM -0500, Sidnei da Silva wrote:
> > I can come up with a stack trace.
>
>IWBN to look at.
Alright, here it is. Now that I look at it, iterSelect() is indeed in
the backtrace, but the assignment is in _init,
On Thu, May 03, 2007 at 03:20:42PM -0500, Sidnei da Silva wrote:
> On 5/3/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> > iterSelect() doesn't do anything with ._connection. Could it be
> >Transaction?
>
> I can come up with a stack trace.
IWBN to look at.
> Just wondering about the behav
On 5/3/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>iterSelect() doesn't do anything with ._connection. Could it be
> Transaction?
I can come up with a stack trace. Just wondering about the behaviour
in general. If you're using a ConnectionHub, is it desirable for
_connection to be overriden
On Thu, May 03, 2007 at 12:40:54PM -0500, Sidnei da Silva wrote:
> I am using a TurboGears app named Tasty and it was acting very
> strangely under heavy loads. I've traced the problem to ConnectionHub
> and its __set__ method. Somewhere inside SQLObject (I've saw
> iterSelect in the call stack) th
I am using a TurboGears app named Tasty and it was acting very
strangely under heavy loads. I've traced the problem to ConnectionHub
and its __set__ method. Somewhere inside SQLObject (I've saw
iterSelect in the call stack) the current connection is assigned to
_connection. This is SQLObject 0.8.2
