[orm-devel] Unified Connection Strings

[Ross J. Reedstrom]

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 
> released().
> 
> 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.

Ross