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

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 - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to