Martijn Faassen wrote:
I intend to add support for a local utility soon,
inspired by some code sent to me by Hermann Himmelbauer.
This is now in there. It only looks faintly like Hermann's code, but it
was still very useful.
You can register an engine factory globally or locally. This engine
factory can be called to create an engine, but it'll return the same
engine again when called again. This way, engines are shared and engine
To make this work for your application/framework you need to subclass
SiteScopedSession and implement siteScopeFunc. You can then register an
instance of that subclass globally (or locally if you should so desire,
but globally is usually enough).
The README was updated to reflect the new situation:
This now works against the trunk of zope.sqlalchemy as well, as Laurence
merged my branch. I do think my code currently requires SQLAlchemy
0.5beta1 or higher.
Overall I'm quite pleased by this code. It's straightforward, and leaves
to SQLAlchemy as much as possible, and just passes configuration
parameters for engines and sessions along if you define them for the
utilities. It doesn't offer any user interface code or schemas itself;
that's up to the application or framework developer. It's also
flexible. Configuration information could be retrieved from any place a
developer would like; hardcoded in Python, or the ZODB. I think it
wouldn't be hard to write custom utilities that look up configuration in
configuration files such as zope.conf or ZCML as well.
One thing I'm not sure about is using _v_engine to store the engine in a
persistent local utility. What if the local utility gets evicted from
the ZODB cache? It'd need to recreate the engine. Anyway, I've left the
policy on how to cache the engine overridable. I'm curious about better
ideas. I considered using a global dictionary with the cached engines in
there, as nothing could get just disappear from that, but I'm not
entirely sure that'd be thread safe. There is a chance that an engine
gets recreated if two threads were to be writing to it at the same time.
Perhaps some thread locking code is required. Opinions?
Feedback is again welcome!
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -