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 the quick reply!
>>
>> On Wednesday, February 21, 2018 a
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 connection + execute sequence within
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
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.
>
> Make sure that e
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.
>> I've added a test case class below to the test_versi
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 to confirm this behaviou
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! That makes sense…
>
> Jens
>
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:
===
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 K
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:
>
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 order dependency between
11 matches
Mail list logo