On Feb 19, 2013, at 10:16 PM, rob.crow...@moat.com wrote: > I'm building a pyramid application using pyramid_tm and > ZopeTransactionExtension. We've written a little subscriber on NewResponse > that writes out some values to a log file about the current user > (request.user.id) after each request. For anybody that knows pyramid pretty > well, we set the request.user property using > config.set_request_property(get_user, 'user', reify=True), but basically we > look up the User object once in our db and then cache it as request.user for > the lifetime of the request. > > For the most part this is working fine, except for in the case that the User > object gets modified during the request (change their avatar, name, password, > whatever). When this happens, we get a Detached Instance exception when we > try to reference the 'id' field of request.user. It's worth pointing out > that pyramid_tm runs and commits our transaction before our NewResponse > subscriber fires, which means that request.user has already been flushed and > committed to the database and appears to be detached (in fact, we can merge > it back into our session and continue using it as normal, see Solution #3 > below). > > We've found 3 work-arounds that seem to give us the desired behavior, but I'm > not really sure which one is better. > > In this case, it seems Solution 1 is the best as it doesn't do any additional > SQL queries (and I'm willing to accept that occasionally I might be writing a > stale User object to disk), but is there any other downside to this approach? > After my subscriber runs the web request is finished, so theoretically it > doesn't matter that the objects are not expired, correct? Is there a better > approach here that I am missing?
definitely solution 1, if you need to keep working with the objects post-commit without any huge gap in between, that's the way to go and it's why that flag is there. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
