[orm-devel] Unified Connection Strings
Ross J. Reedstrom
Mon, 2 Dec 2002 10:56:01 -0600
On Mon, Dec 02, 2002 at 10:50:11AM +0100, Diedrich Vorberg wrote:
> Hi Ross,
> This is my solution using a Zope SQL DA (ZPsycopgDA), just
> subclassing the PostgreSQL datasource.
> class datasource(orm.adapters.psql.datasource.datasource):
> We're using Zope's mechanism for database connections here.
> This is a subclass of orm's psycopg adapter.
> def __init__(self, context):
> zope_ds = context.restrictedTraverse("zope_ds")
> self._conn = zope_ds().db
> self._encoding = "iso-8859-1"
> self._dsn = ""
Ah, this looks useful.
> The problem I can see is, that there is only one connection to the
> database. PostgreSQL will maintain transactions connection-wise. So
> if one of my threads runs a couple of queries on one connection and
> another runs a rollback() on that connection my changes are lost.
> Even an unwanted commit() might lead to trouble.
Yup, you've _got_ to use the connection pool.
> The Zope Product I'm currently working on is in the CVS contrib
> directory, but be warned it, is rather primitive :-) It provides
> (besides the Zope Management facilities) two methods: aquire() and
> release(). There is a minium and maximum number of connections the
> Pool will create to the RDBMS. aquire() will return one to you if
> one is available or open a new one for you. If the maximum number of
> open connections is reached it will make you wait until one is
> This is untested, I'm going to start working with it today.
Hmm, so this means your build a connection pool on top of the existing
Zope connection pool? I thought the Zope pool was careful about not
letting multiple Zope threads use the same connection. If you've seen
otherwise, however ... Or is your orm-using app also using threads itself?
orm doesn't multithread on it's own, right?
> There is a rather nasty problem with ORM and Zope. ORM requires
> Python 2.2, because of Python's builtin classmethod(). Zope will warn
> about 2.1 being the preferred version to run it with, but to my
Right, I already ran into this. So, I've seen a number of partial
implementations of classmethod() for use on 2.1: there's one on ASPN,
one in the cookbook, and one I just saw on python-list in June. How
unlikely would it be to get orm-cvs to work under 2.1? Hmm, I see the
next hurdle is subclassing from the 'list' builtin.