On Mon, 2011-11-14 at 20:30 +0100, Vlad K. wrote: > For worse I'd say because using SQLAlchemy directly works just fine and > as expected, without the need to reload the data after failed session. > > Is there any benefit of the Transaction in Pyramid if all I'm using is > it for is SQLAlchemy (and don't need transaction abstraction)? In fact > I'm only using it because pyramid_routesalchemy template uses it by default. > > Aside to commit veto in the middleware, am I losing anything if I remove > pyramid_tm altogether and use SQLAlchemy directly? Yes, I know I'll have > to manually commit at the end of each request or write my own middleware...
You can use it or not use it as you see fit. - C > > > Thanks! ;) > > .oO V Oo. > > > On 11/14/2011 07:50 PM, Chris McDonough wrote: > > On Mon, 2011-11-14 at 13:41 +0100, Vlad K. wrote: > >> Here: > >> > >> https://gist.github.com/1363860 > >> > >> This simple test case works just fine, meaning the problem is somewhere > >> in my application. As you can see from the code, I tried both a > >> "standalone" test and through Pyramid WSGI chain checking if pyramid_tm > >> middleware possibly borks something somewhere, but both cases worked fine. > > > > I think the issue here is that (for better or worse), calling > > transaction.commit() causes the session to be closed, which detaches the > > objects obtained from that session. The following iteration on your > > script actually completes (note that I requery for "tm" after "second > > pass").... > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
