gmPgObject (was Re: [DB-SIG] [ANN] SQLObject 0.1)

[Horst Herb]

On Tue, 22 Oct 2002 10:55, Ian Bicking wrote:
> This is the first release of SQLObject (v0.1).
>
> SQLObject is an object-relational mapper.  It's meant to make database
> rows look like normal Python objects -- no dictionary access, no

We are working on a similar object-relational mapper, though ours is highly 
specific for PostgreSQL and depending on a few of our own internal modules 
(managing connection pools etc).

Our approach automatically follows (dereferences) rows referenced via foreign 
keys, and  changes are committed on object deletion, change of primary key 
value or on manual committ.

When new objects are created, the new primary key is initialized via backend, 
and the object is refreshed from the backend thus respecting all backend 
defaults/constraints - all you need to do is creating the object and 
attemptimg to access/modify any column and it happens automagically.

It is particularly easy to use, since all table metadata is gathered and 
cached in the background. All fetches are "lazy" unless forced, meaning no 
queries are executed unless the columns are really accessed:

row = pgobject(<connection pool broker>, <table name>)
row.fetch(<primary key value>)

row["some column"] = some_value
row["foreign key"]["referenced table column"] = some_value

However, it is not nicely written (quick hack so far), hardly any exception / 
error handling at all yet, no performance considerations yet, and probably 
still full of bugs.

There is a definite problem because of the lack of nested transactions in 
PostgreSQL for which we haven't found a good solution yet

That said, I think our concept is sound and I'd love to attract a few people 
working on this together for mutual benefit.

Have alook at the CVS file in
http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/client/python-common/gmPgObject.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

Horst, coordinator "The Gnumed Project" http://gnu.org/software/gnumed