[Zope-dev] Re: zope.sqlalchemy

[Michael Bayer]

On May 7, 2008, at 2:29 PM, Laurence Rowe wrote:

> When the generic address book application is built you don't know  
> what the departments will be called or indeed how many departments  
> there are. An address book is not be a great example, but I know of  
> intranet portal sites where this is a requirement. You want to  
> delegate control to each department so you give each department  
> their own instance of the portal. You only want to maintain one code  
> base though, and you don't want to change it every time someone adds  
> another departmental portal. I'd like to be able to create an add  
> form that has fields for application name and database url.
>
> This probably seems like an odd requirement -- why not just run  
> multiple processes with different configurations -- but it's the way  
> zope has traditionally worked. A single process can serve multiple  
> instances of the same application (or `site`). When you get up to  
> running tens of sites, the memory footprint of Zope2 and Plone   
> (before the object cache) becomes significant.

If you are running different instances each connected to a different  
engine within one process you wouldn't need any awareness of engines  
at the object level (therefore no entity_name) and also no engine  
proxying - you should have separate Session instances for each  
"process" managed by scoped_session(),  which was designed to handle  
this.    Multiple apps on one codebase within one process was an  
original requirement of Pylons as well, though nobody has ever used it.

The easiest way to do it is to set up the engine at the request level:

Session = scoped_session()

# start of request
engine = get_appropriate_engine()
Session(bind=engine)
try:
	# do request
finally:
	Session.remove()

If that isnt granular enough, then you use a custom scope func which  
maintains Session per-"process"-per-thread.