On May 26, 3:31 pm, "Michael Bayer" <[email protected]> wrote:
> Bob Farrell wrote:
>
> > Hi Michael, I found this (your writing) in a thread from quite a while
> > back:
>
> >> A common pattern which can cause what you see there is if your
> >> templates are accessing lazy loaders on objects, but the Session which
> >> loaded those objects had been clear()'ed or otherwise closed before
> >> the template was allowed to render. You should try to keep the same
> >> Session open throughout the full request lifecycle, and you should
> >> avoid removing any objects from the Session which you wish to continue
> >> using.
>
> > Hi - came across this because I've started getting the same problem
> > and was somewhat relieved to see that the solution is a well-known one
> > (given that rendering the template raises this error). I have code
> > like this:
>
> > [do stuff involving the session]
> > return self.render_response('settings.mako', t_pars)
>
> > in my controller methods and it's the return where the error gets
> > raised. Can you tell me a good approach for making the session stay
> > alive here ? I'm assuming the problem is that self.render_response
> > returns something lazy and so by the time the template actually
> > renders the objects relating to the session have gone out of scope.
>
> the whole request is wrapped within a block that handles Session
> lifecycle, so that the Session is still just fine when render_response is
> being called. In Pylons, an appropriate base.py is provided for you which
> does this. A description is
> athttp://www.sqlalchemy.org/docs/05/session.html#lifespan-of-a-contextu...
> .
>
> The Session has a behavior whereby after a commit(), it expires its
> contents. This so that it reloads everything upon access to get access to
> what any concurrent transactions have done. If your pattern is something
> like this:
>
> Session.commit()
> return self.render_response(...)
>
> your render phase may issue a lot of SQL to reload things (though nothing
> should break). Two ways to work around this are to set
> expire_on_commit=False in your sessionmaker(), or to wrap your whole
> controller method in a commit, such as:
>
> @commits_transaction
> def my_method(self):
> <do stuff>
> return self.render_response(...)
>
> commits_transaction looks like:
>
> @decorator
> def commits_transaction(fn, self, *args, **kw):
> try:
> ret = fn(self, *args, **kw)
> Session.commit()
> return ret
> except:
> Session.rollback()
> raise
>
> the rollback() may not be needed if your overall handler calls rollback()
> in all cases.
Great, thanks very much - looks like gutting our horrible connection-
handling code and moving to scoped_session is really making things
better and this should (hopefully) be the last problem needing ironing
out. Shouldn't be a problem given what you mentioned above. You have,
as ever, been a tremendous help. :-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
