Michael Bayer wrote:
[snip discussion on BoundMetadata I don't comprehend yet but probably
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?
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 -