[Gnumed-devel] database abstraction

[Horst Herb]

I have given it another shot at a database abstraction layer.
It is in client/python-common/gmPgObject.py
It deals with abstraction of single rows resulting from a query and related 
"child rows" as referenced by foreign keys.

usage:

row = pgobject(connection, table, <primarykey>)
> initializes the object (gets cached meta data for the table)
> if <primarykey> is > 0, the row identified by primarykey is marked for 
fetching
dummy = row[column]
works already.
row[column] = 'dummy'
is halfways implemented.

Difference between this abstraction and simple dictionary objects / 
pgresultsets:

1.) lazy queries: queries are only executed when columns are accessed
2.) metadata caching: including details of primary keys and foreign keys!
3.) *writeable* object (not fully implemented, but easy now): data gets 
written to backend if
- object (fetched or new) deleted after modification
- primary key modified (new fetch)
- forced by user via save()
4.) automatic (lazy) creation of child objects referenced by foreign keys (not 
implemented yet, but easy now that I have the cached foreign key meta data)

API is not stable yet. I am still thinking about many to many relationships 
and automatic child object creation (lazy, on demand). Currently I have a 
pgobject.SetManyToMany(<pivot table name>) in mind as most simple solution, 
but I would prefer something more automatic, automagically derived from 
metadata

CAREFUL: This class wants a *list* returned by cursor.fetch... - as opposed to 
the default pgresultset as returned by pyPgSQL! The resulting performance 
boost makes up for some of the performance loss via this abstraction.

Suggestions welcome. Maybe Hilmar wants to merge the best aspects of his drug 
metadata class with this one?

Horst