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)



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to