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

[Martijn Faassen]

Hey,

Michael Bayer wrote:

[snip discussion on BoundMetadata I don't comprehend yet but probably 
should :)]

> 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.  

Is it really needed to set things up at the start and the request and 
tear things down on the end, or can a session be retained between 
requests? I.e. is the intent to recreate a Session class each time a 
request is issued?

> 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.   

This indicates to me is possible to retain a Session object between two 
requests? I.e. it's a worthwhile goal to reduce the amount of Session 
configuration going on, right?

> 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.

I'm trying to understand why you think so. I am looking for a way to let 
developers use SQLAlchemy in a straightforward way. They should be able 
to import 'Session', instantiate session in their app, and everything 
works as expected. The framework takes care of making you get the 
appropriately configured Session.

That underneath sessions are scoped per thread and per app, and 
configured per app, is something the developer who handles the session 
object ideally should not have to worry about. Since I hope we can 
actually make this work, why do you think an explicit approach with a 
custom registry which then contains scoped sessions would be better? The 
less of our own new registries we invent the better, I'd say.

That said, I guess you could make the same semantics work if you make 
Session be some factory that uses a nested registry.

(I'd still absolutely like to avoid passing in context explicitly each 
time you need a session; it puts unnecessary burden on the developer and 
promises to make multi-application interactions easier while it actually 
doesn't do so)

Regards,

Martijn