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:
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
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.
Laurence
_______________________________________________
Zope-Dev maillist - Zope-Dev@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 )
