[Zope-dev] Re: zope.sqlalchemy, integration ideas

[Michael Bayer]

On May 28, 2008, at 7:09 PM, Laurence Rowe wrote:

>
> Engine configuration is a subset of session configuration. You  
> cannot have a single ScopedSession for a package if you want to have  
> multiple instances of that application. We must work with unbound  
> metadata if we have this goal. That implies that we must use bound  
> sessions, a session associated with a particular engine (actually it  
> could be more complex than this, you can associate particular  
> classes/tables with particular engines within a session).

<chiming in, although I haven't read the whole thread....>

I would agree that "bound" metadata is a little cumbersome in an  
environment that wants to switch engines within a single process.     
"Bound" metadata has always given us a lot of headaches because it's  
just *so* convenient that we just can't get rid of it, but at the same  
time people are just so tripped up by it, thinking it's necessary to  
make anything happen (it's not).  Binding sessions allows better  
control of connection/transaction scope (since the Session relates to  
transactions, MetaData does not), so it's probabably the way to go in  
an environment that has a lot of things going on.

As far as ScopedSession, it's really just a thread local variable.   
Like any global threadlocal, you can stick whatever you want on it at  
the start of a request, and tear it down at the end.   Then again it's  
also reasonable that you might want to have individual ScopedSessions  
for each application instance within a multi-app process, that way the  
burden of setting up/tearing down is reduced or removed.   A single  
ScopedSession for a multi-app process is like a one-dimensional  
approach where both current thread and current app are identified by  
the current "get()" of the registry; a collection of ScopedSessions is  
more like a two-dimensional approach where the first level of registry  
(i.e. which ScopedSession do I choose) distinguishes between app  
instance, and the second level (i.e. what Session is bound to this  
thread ID) distinguishes between threads.

All of that said I think it can work either way but I think the latter  
approach might have the explicitness you're looking for.