Martijn Faassen wrote:
Hi there,

In some earlier discussions a number of approaches to integrate SQLAlchemy into Zope were discussed. Following up on that, I've tried a particular approach that tries to use ScopedSessions with a custom scope that isn't just per thread, but also per site (application). The benefit of this approach is that it should allow the following to just work:

from z3c.sa_integration import Session

def somewhere_in_a_view(self):
    session = Session()
    return session.query(Test).all()

where 'Session' is a custom SA scoped session.

I've checked in my (documented) experiment in here:


The interesting bits are here:

See the documentation in that file for more information.

The one bit I'm not happy about yet is the way engines need to be global utilities now. I'd like it to be possible for users to edit the database connection parameters through the web. I have a sketchy idea about how to solve this by registering engines as non-persistent local utilities, but it's still unclear how they'd get created at the right time. It might also be possible to simply implement the engine method on IDatabase to create the engine when called the first time, and then cache it in a volatile property. I think this is something Laurence Rowe has been talking about. I'm not sure whether it's a good idea to rely on the ZODB cache, but it might be possible to simply cache the engines in a global registry...

Comments? Suggestions?

zope.sqlalchemy recycles sessions, so I don't believe it's necessary to keep a registry of engines, or even to cache them on a volatile property. They are only required during session creation, which happens only once per thread per configuration. The session itself always retains a reference to the engine of course.

The downside of doing session.close() rather than session.remove() at the end of a transaction is that it becomes difficult to change configurations, as the configuration() method is not called again.

I guess the way to work around this is to build a revision into the scopeing function, perhaps using the _p_mtime of the configuration object. (it would be nice to use _p_oid in the scope, but that is not set until the transaction that creates the configuration is committed).

There would be straggling sessions and open db connections left in the scoped session with this approach, but I don't really see a way to avoid that without lots of messy locking.


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to