On 7/11/07, Paul Johnston <[EMAIL PROTECTED]> wrote: > > Hi, > > >SAContext is strictly a configurational object, it doesnt add any new > > > > > I see. I had wondered if this was WSGI middleware that took care of > database transactions (as has been mooted in the TG area recently). > Obviously as a config object, it can't do either of the things I suggested.
It's not middleware, it's just a container for engines/metadatas/sessions. A draft of the docstring said, "SAContext organizes your SQLAlchemy engines, metadatas, and sessions into one convenient object. That's *all* it does." Maybe I should put it back. :). For data freshness problems, put sac.session.clear() at the beginning of each request, ideally in common code that all requests execute. In Pylons you'd put it in the base controller's .__call__ method (myapp/lib/base.py). I don't know the TG equivalent. You can also try the other SQLAlchemy idiom: "del sac.session_context.current", which is supposedly slightly faster than calling clear. For MySQL disconnection errors, use 'pool_recycle' as Mike said. I also tried to get Mike to put auto-retry code into SQLAlchemy but he said the same thing: that it brought up transaction issues. I meant to put both those things into the docstring along with an example of assign_mapper. I just put them in now (without incrementing the version). -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
