[Zope-dev] SQLAlchemy integration experiment

Brian Sutherland brian at vanguardistas.net
Tue Jun 17 03:16:43 EDT 2008


On Mon, Jun 16, 2008 at 08:40:24PM +0200, 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()

For some reason this raises a warning bell in my head. I keep on
thinking: this is zope, the session is a classic case for a utility, we
should be getting it in views by an interface.

That may be because I've already become too fixed in the way I think
about things.

However, Laurence's point about database re-connection is relevant here.
If the Session were looked up by an interface, someone could implement
seamless database re-connection (lots of complex code) without polluting
zope.sqlalchemy.

> where 'Session' is a custom SA scoped session.
>
> I've checked in my (documented) experiment in here:
>
> svn://svn.zope.org/repos/main/Sandbox/faassen/rdbintegration/trunk
>
> The interesting bits are here:
>
> http://svn.zope.org/Sandbox/faassen/rdbintegration/trunk/src/rdbintegration/app.py

This looks very nice. I'm not sure IDatabase.engine is necessary, it
seems to be only used internally to Database. Also, any view code
should really be getting the connection directly from the session.

> 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?

As Laurence has suggested, the session persists, so
IDatabase.configuration will only be called once per thread. Not sure if
creating one new engine per thread is bad.

>
> Regards,
>
> Martijn
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )

-- 
Brian Sutherland


More information about the Zope-Dev mailing list