your database logs may indicate why it is closing the connection or what
underlying error happened.
there are dozens, if not hundreds, of potential reasons why an error like
this may be happening. this could be from anything, including having too
many connections, to an issue on your database
@jonathan
I went through that. What is the possible reason for disconnect ? I am not
restarting my dbs.
On Monday, 15 October 2018 20:43:45 UTC+5:30, Jonathan Vanasco wrote:
>
> There are a few strategies to handling disconnects that are outlined in
> the docs:
>
>
>
There are a few strategies to handling disconnects that are outlined in the
docs:
https://docs.sqlalchemy.org/en/latest/core/pooling.html#dealing-with-disconnects
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please
More information
Similarly, we are creating a scoped session, we are doing session.close()
*I tried Null Pool which doesn't help*
Any ideas on that?
Relevant finding Is it odd that my SQLAlchemy MySQL connection always ends
up sleeping?
Yep, using populate_existing() in the second query makes test_2 work.
W dniu poniedziałek, 15 października 2018 15:41:23 UTC+2 użytkownik Mike
Bayer napisał:
>
> On Mon, Oct 15, 2018 at 9:27 AM Simon King > wrote:
> >
> > This is an interesting question. Here's my explanation of what's going
Hi
Flask with SQLAlchemy
Flask==0.10.1
SQLAlchemy==1.0.8
In production after a lot of usages (connection) we are getting this error.
After that restarting the server helps, what will be the permanent solution
OperationalError: (psycopg2.OperationalError) server closed the connection
Yep, it totally makes sense. When it comes to the question you suggested,
it seems to me misleading that query parameters may affect further queries.
On the other hand, I understand that there are some optimizations in
sqlalchemy
which may cause behavior such as this.
That's why I am not sure if
On Mon, Oct 15, 2018 at 9:27 AM Simon King wrote:
>
> This is an interesting question. Here's my explanation of what's going on:
>
> When you run a query using a loader option such as raiseload,
> SQLAlchemy constructs your instance and attaches the "raiseload"
> behaviour to that instance. In
This is an interesting question. Here's my explanation of what's going on:
When you run a query using a loader option such as raiseload,
SQLAlchemy constructs your instance and attaches the "raiseload"
behaviour to that instance. In your test_1, this happens, but since
you don't store the result,
Hi,
I observed some strange (for me) behavior related to setting query options.
I am not sure if it works as intended or it is a bug.
It seems to me that options are applied to query in a strange manner. The
posted below the code that show this behavior:
1) in both tests I am configuring
10 matches
Mail list logo
