Michael Bayer wrote:
(I'm guessing session.merge will whine if handed an object that is
already in another session?)
mm no merge() leaves the original unaffected. it copies state to an
instance internal to the session. this is very clear here:
On May 4, 2010, at 1:59 PM, Chris Withers wrote:
So putting non-expunged objects in something like a beaker cache would be a
no-no, correct? (would .close() or .remove() fix the problem if the objects
are already in the cache by the time the .close() or .remove() is called?)
in most cases
On Apr 29, 2010, at 3:21 AM, Chris Withers wrote:
Michael Bayer wrote:
if your application keeps a handle on objects after the request is
complete, and then passed them somewhere else, like a background thread or
something, then the subsequent request is going to be potentially touching
Michael Bayer wrote:
if your application keeps a handle on objects after the request is
complete, and then passed them somewhere else, like a background thread or
something, then the subsequent request is going to be potentially touching
those objects at the same time. This would all be pretty
-Original Message-
From: sqlalchemy@googlegroups.com
[mailto:sqlalch...@googlegroups.com] On Behalf Of Chris Withers
Sent: 28 April 2010 14:37
To: sqlalchemy@googlegroups.com
Subject: [sqlalchemy] session lifecycle and wsgi
Hi All,
I'm still trying to get an answer on this...
Hi Chris:
I'm a bit hesitant to share what I've done, b/c it's still a work in
progress etc, but here goes:
MySQL MyISAM, wait_timeout=28800
SQLAlchemy 0.5.6, pool_recycle=3600
I've written a few decorators (mostly stolen from SQLAlchemy docs
examples):
def with_query_write(fn):
Diana Clarke wrote:
I'm a bit hesitant to share what I've done, b/c it's still a work in
progress etc, but here goes:
MySQL MyISAM, wait_timeout=28800
You have no transactions, so I'm not sure why you're worrying about
them... Switch to InnoDB if you want transactions...
Finally,
On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote:
Diana Clarke wrote:
Finally, we're using pylons and are removing the contextual session in the
finally clause of the base controller's __call__ method.
class BaseController(WSGIController):
def __call__(self,
Yup, no transactions (legacy, can't switch anytime soon) which is why
I didn't originally write any rollback framing... but I was still
getting the following error after MySQL raised a 2006 (until app
restart), and a quick peek at _handle_dbapi_exception seemed to
suggest that I needed to issue
jason kirtland wrote:
On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote:
Diana Clarke wrote:
Finally, we're using pylons and are removing the contextual session in the
finally clause of the base controller's __call__ method.
class BaseController(WSGIController):
On Wed, Apr 28, 2010 at 8:55 AM, Chris Withers ch...@simplistix.co.uk wrote:
jason kirtland wrote:
On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk
wrote:
Diana Clarke wrote:
Finally, we're using pylons and are removing the contextual session in
the
finally clause of
jason kirtland wrote:
On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk
wrote:
Diana Clarke wrote:
Finally, we're using pylons and are removing the contextual session in
the
finally clause of the base controller's __call__ method.
class BaseController(WSGIController):
Diana Clarke wrote:
Yup, no transactions (legacy, can't switch anytime soon) which is why
I didn't originally write any rollback framing... but I was still
getting the following error after MySQL raised a 2006 (until app
restart), and a quick peek at _handle_dbapi_exception seemed to
suggest
Michael Bayer wrote:
If finishing with a .remove() is a big deal in your environment, which
it seems like it is, you could do a .remove() at the start of the
request instead.
You really don't need the remove() if you have definitely called
commit() or rollback() last, and you have
Chris Withers wrote:
Michael Bayer wrote:
If finishing with a .remove() is a big deal in your environment, which
it seems like it is, you could do a .remove() at the start of the
request instead.
You really don't need the remove() if you have definitely called
commit() or rollback() last,
15 matches
Mail list logo
