[sqlalchemy] Re: is pool supposed to be able to handle its target db restarting?

2007-01-27 Thread Michael Bayer
On Jan 26, 2007, at 6:05 PM, Jonathan Ellis wrote: On 1/26/07, Michael Bayer [EMAIL PROTECTED] wrote: doing away with the __del__() thing ? what would we gain by removing the __del__() call ? relying on it is buggy. so why have it? youre basically saying, do away with implicit

[sqlalchemy] Re: is pool supposed to be able to handle its target db restarting?

2007-01-26 Thread Michael Bayer
On Jan 26, 5:49 pm, Michael Bayer [EMAIL PROTECTED] wrote: doing away with the __del__() thing ? what would we gain by removing the __del__() call ?one thing I should do is insure ORM etc. do not rely upon __del__() (which they shouldnt, although I just tested with the AssertionPool

[sqlalchemy] Re: is pool supposed to be able to handle its target db restarting?

2007-01-25 Thread Jonathan Ellis
I'm restarting it after the first fetchall() finishes. My experience with postgresql/psycopg2 is that you can tell the connection is dead when you next try to call cursor(), but that isn't happening here because of the queue problem I described. Here's the output with pool logging on, if that