Hi all,
Actually, i have some problem closing my session...
I tried using scopedsession with session.remove
I tried using normal session with session.close
But in both cases, the Mysql session stay open.
Why closing session has no effet on current Mysql connections ?
--
You received this
Is it bad to use one session within app and never close it?
On Friday, January 31, 2014 9:04:01 AM UTC+4, Pavel Aborilov wrote:
I need to have access to this state in a whole life of app, but as I
undestand it's not a good way to use one session all time.
Proper way, to open session, do all
On Fri, Feb 7, 2014 at 9:28 AM, Christian Démolis
christiandemo...@gmail.com wrote:
Hi all,
Actually, i have some problem closing my session...
I tried using scopedsession with session.remove
I tried using normal session with session.close
But in both cases, the Mysql session stay open.
you don’t need the session to be open to access object state. when you close
the session, the objects that were in it become detached. if you are referring
to them elsewhere, they still work fine. they just won’t know how to go out
and access a database. if that’s all you need, you’re done.
On Feb 7, 2014, at 11:01 AM, Claudio Freire klaussfre...@gmail.com wrote:
I've had similar issues with 0.7.10. SA opens an implicit transaction,
incorrect, DBAPI does this, please see:
http://www.python.org/dev/peps/pep-0249/#commit
there is no “explicit transaction” in DBAPI. The docs
I knew I should've been more explicit
On Fri, Feb 7, 2014 at 1:07 PM, Michael Bayer mike...@zzzcomputing.com wrote:
On Feb 7, 2014, at 11:01 AM, Claudio Freire klaussfre...@gmail.com wrote:
I've had similar issues with 0.7.10. SA opens an implicit transaction,
incorrect, DBAPI does this,
On Wed, Feb 5, 2014 at 7:28 PM, Michael Bayer mike...@zzzcomputing.comwrote:
OK great, added some more rules in 5c188f6c1ce85eaace27f052.
Awesome, thanks! My tests all passed on my end.
As far as “names line up with the result set names”, I’m not sure what you
mean there, the .columns()
On Fri, Feb 7, 2014 at 2:35 PM, Michael Bayer mike...@zzzcomputing.com wrote:
The connection pool, if in use, will then not
actually close the connection if it is to remained pooled, it calls
rollback() as part of the pool release mechanism. Recent versions of
SQLAlchemy allow this to show up
On Feb 7, 2014, at 1:00 PM, Matt Phipps matt.the.m...@gmail.com wrote:
I wrote one more test that failed (but I'm pretty sure it doesn't matter): I
was under the impression that passing Label objects to .columns() would allow
you to map arbitrary result set column names to ORM attributes,
On Feb 7, 2014, at 11:16 AM, Claudio Freire klaussfre...@gmail.com wrote:
and neither Session.remove nor Session.close really roll back the
transaction
No, but the connection pool should. (reset_on_return, which I have enabled)
reset_on_return is on by default. the pool has always emitted
On Fri, Feb 7, 2014 at 11:51 AM, Simon King si...@simonking.org.uk wrote:
On Fri, Feb 7, 2014 at 9:28 AM, Christian Démolis
christiandemo...@gmail.com wrote:
Hi all,
Actually, i have some problem closing my session...
I tried using scopedsession with session.remove
I tried using normal
Sounds great; I agree avoiding the naming convention is ideal. For my
project the only reason we're using a text clause is to call a stored
procedure, which definitely can't go in a subquery, so I'm not sure how
well I can weigh in on the aliasing stuff.
-Matt
On Fri, Feb 7, 2014 at 1:43 PM,
12 matches
Mail list logo
