On Jul 3, 2008, at 5:05 AM, Iwan wrote:
> I was wondering if it is not possible to do something that is local to > the current call-stack, instead of the current thread. I think there > are two issues here: > a) a general mechanism for remembering a call-local context > b) using it to provide a call-local sqlalchemy session > > Now, I'm not sure yet how to do (b), but want to give an example of > (a) with a naive implementation to illustrate the idea. (Just note > this mechanism can be used for other important contextual info as > well, such as who the current user is, etc) > > With the following code, I can call a method b.bar, passing it some > "context" (which is not part of the method's original signature). > b.bar calls a.foo in turn, also not passing it anything, but inside > A.foo, the context can be retrieved from the call stack. The only > overhead incurred is during this last step, and I don't think it is > much. (Implementation of CC is at the bottom.) > > Any thoughts? the "currentframe" usage is something I'd leave to the deeper Python folks to argue over its appropriateness. As far as SA's contextual session, it was always meant to allow any kind of context, not just threadlocal. Here, it would look like: Session = scoped_session(sessionmaker(), scopefunc=get_context) where "get_context" needs to return anything that is hashable, to key off to the Session inside of a dict. We have at least one user who used this function in the past to relate Sessions to graphical windows. So give it a try ! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
