Sorry, I just saw the "the Mapper class itself and the mapper()
function indicate listening for all mappers." on the latest docs.
Thanks.
On Wed, Apr 8, 2015 at 5:27 PM, Mike Bayer wrote:
>
>
> On 4/8/15 5:14 PM, Tim Tisdall wrote:
>
> I have some code I'm tryin
I have some code I'm trying to figure out... Here it is:
from sqlalchemy import event
from colanderalchemy import setup_schema
from sqlalchemy.orm import mapper
event.listen(mapper, 'mapper_configured', setup_schema)
It appears to call `setup_schema` on every ORM class that derives from the
`
etting messages like that. Or are the pool connections "recycled" just
before the next use and not after 4hrs elapse?
-Tim
On 27 March 2014 11:44, Michael Bayer wrote:
>
> On Mar 27, 2014, at 10:03 AM, Tim Tisdall wrote:
>
> > Today I found the following traceback in
Have you tried turning the SQLAlchemy logging on to see the SQL queries
that are run on your sample program? I've found it very helpful when
trying to debug why something is not working the way I expected. You _may_
be able to do it as follows:
import logging
logging.getLogger("sqlalchemy.eng
Today I found the following traceback in my logs:
2014-03-27 13:55:59,876 ERROR [sqlalchemy.pool.QueuePool _close_connection
b'uWSGIWorker2Core14'] Exception closing connection
Traceback (most recent call last):
File
"/sites/ColanderAlchemy/SQLAlchemy-0.9.3-py3.3-linux-x86_64.egg/sqlalchemy/p
Thanks, that does clear up some of the components for me.
On Tuesday, 25 March 2014 16:05:26 UTC-4, Simon King wrote:
>
> On 25 Mar 2014, at 19:05, Tim Tisdall >
> wrote:
>
> > I've been reading through the SQLAlchemy docs for a while now and am
> still fairly co
After putting more logging on it seems that `with transaction.manager`
contexts are committing and returning the connection to the connection pool
as I'd hoped.
However, I began looking into this more because I got a "MySQL server has
gone away" error despite having "sqlalchemy.pool_recycle = 1
I've been reading through the SQLAlchemy docs for a while now and am still
fairly confused about using SQLAlchemy with threaded processes. Hopefully
my specific question helps me understand things a little more...
I'm using the Pyramid framework with SQLAlchemy. The default scaffold for
this
y bind the Session
> to a connection like this:
>
> conn = engine.connect()
>
> sess = Session(bind=conn)
>
> otherwise, just sending through the "commit" on the DBAPI connection
> directly might not be so terrible. If you said,
> session.connection().conne
ction to the threadpool.
This seems kind of a hack, but does anyone have a better solution?
On Fri, Aug 23, 2013 at 4:12 PM, Tim Tisdall wrote:
> I'll try to make this succinct...
>
> I'm creating a temporary table and then doing a query with it that takes a
> good length of
I'll try to make this succinct...
I'm creating a temporary table and then doing a query with it that takes a
good length of time. I found that the source tables going into the
temporary table were being locked after the temporary table was created
even though they were no longer needed for the
11 matches
Mail list logo
