Re: [sqlalchemy] SQLAlchemy lock-up when logging to a database

or have your logger look for that "log_only" token in the logger name and skip on that, that's more future-proof. On Wed, Feb 21, 2018 at 4:30 PM, Mike Bayer wrote: > On Wed, Feb 21, 2018 at 2:34 PM, Stefan Schwarzer > wrote: >> Thanks for

Re: [sqlalchemy] SQLAlchemy lock-up when logging to a database

On Wed, Feb 21, 2018 at 2:34 PM, Stefan Schwarzer wrote: > Thanks for the quick reply! > > On Wednesday, February 21, 2018 at 6:44:33 PM UTC+1, Mike Bayer wrote: >> >> I can come up with other things that can break based on the idea that >> you're doing a full

Re: [sqlalchemy] SQLAlchemy lock-up when logging to a database

Thanks for the quick reply! On Wednesday, February 21, 2018 at 6:44:33 PM UTC+1, Mike Bayer wrote: > > I can come up with other things that can break based on the idea that > you're doing a full connection + execute sequence within the log > handler deep within that engine's own processes, such

Re: [sqlalchemy] SQLAlchemy lock-up when logging to a database

On Wed, Feb 21, 2018 at 7:16 AM, Stefan Schwarzer wrote: > In our project we recently ran into the problem that SQLAlchemy would > block when creating a connection for logging to a database. > > > def emit(self, record): > """ > Emit the log record.

Re: [sqlalchemy] Problems with versioning when using a class mapped on a select of a table in SQLAlchemy 1.2

On Wed, Feb 21, 2018 at 10:04 AM, Mike Bayer wrote: > On Wed, Feb 21, 2018 at 6:33 AM, Jeff Horemans wrote: >> When migrating from 1.1 tot 1.2, we noticed that the version_id is not >> getting set on a class that maps to a select of a table. >>

Re: [sqlalchemy] Problems with versioning when using a class mapped on a select of a table in SQLAlchemy 1.2

On Wed, Feb 21, 2018 at 6:33 AM, Jeff Horemans wrote: > When migrating from 1.1 tot 1.2, we noticed that the version_id is not > getting set on a class that maps to a select of a table. > I've added a test case class below to the test_versioning.py included in > SQLAlchemy

Re: [sqlalchemy] Session's dialect's server_version_info may be None? (Execution order dependency)

it's not unheard of that people sometimes do a quick ping, like : engine = create_engine(...) engine.scalar("select 1") just to get it connected and initialized with server information. On Wed, Feb 21, 2018 at 6:26 AM, wrote: > Simon, thank you for the reference!

[sqlalchemy] SQLAlchemy lock-up when logging to a database

In our project we recently ran into the problem that SQLAlchemy would block when creating a connection for logging to a database. Set-up: Oracle server 11.2 cx_Oracle 6.1 SQLAlchemy 1.2.3 The example code for `connection_lockup.py` is:

[sqlalchemy] Problems with versioning when using a class mapped on a select of a table in SQLAlchemy 1.2

When migrating from 1.1 tot 1.2, we noticed that the version_id is not getting set on a class that maps to a select of a table. I've added a test case class below to the test_versioning.py included in SQLAlchemy to confirm this behaviour. This case runs fine in versions 1.0 and 1.1, but gives a

Re: [sqlalchemy] Session's dialect's server_version_info may be None? (Execution order dependency)

Simon, thank you for the reference! That makes sense… Jens On Wednesday, February 21, 2018 at 7:15:20 PM UTC+10, Simon King wrote: > > SQLAlchemy doesn't connect to the database until it needs to. Creating > a Session by itself does not cause it to connect. This is mentioned in > the docs: >

Re: [sqlalchemy] Session's dialect's server_version_info may be None? (Execution order dependency)

On Wed, Feb 21, 2018 at 6:14 AM, wrote: > Hello, > Suppose I create a db session the normal way: > engine = engine_from_config({"sqlalchemy.url":"mysql+pymysql://…"}) Session = sessionmaker(bind=engine) session = Session() > > I noticed that there is now an