Re: [Gnumed-devel] database abstraction

[Hilmar Berger]

On Fri, 25 Oct 2002, Horst Herb wrote:

> This would be my preferred first step of implementing abstraction.
> The second step would be server side functions.
> The third step on top of this is using gmPgObject.
> 
> When you can use a syntax like <view or table name>.[<attribute>] or even 
> <view or table name>.<attribute> when we would limit ourselfes to Python >= 
> 2.2 for read AND write access to these tables or views, it makes life a lot 
> easier.
> ... 
> The beauty of it is that all you need to know is the table and service name 
> at 
> the time you create the object. Whenever a table structure is modified or 
> expanded, you don't have to change your code at all - since the objects are 
> generated on the fly depending on the metadata, they will include all changes 
> automatically.

I generally agree with that design, however, there is one difference
bitween gmPgObject and gmDrugObject: the first targets tables/views , the
second targets queries.  If I understand the idea of gmPgObject correctly,
there is - at least until now - no way to say something like "I want all
drugs containing digitoxin and being available as a tablet containing
2.5mg drug each". As far as I could understand, PgObject identifies rows
only by a primary key. That would mean, in the example above, that you
would have to fetch three (possibly large) lists and find the appropriate
drug yourself. Which would mean that we have to implement business logic
on the client side.  I would prefer an interface that is not only able to
hide table access but hides queries, too. I.e. say something like

myDrug=getDrug({'generic': 'digitoxin', 'formulation': 'tablet', 'dose':
2.5})  

and the query is constructed automatically and the results delivered.
The important thing here is that the query should be run on the backend
side (via a SELECT foo FROM aTable, anotherTable WHERE
aTable.a='digitoxin' AND anotherTable.b=2.5;)

Actually, I wished we had an interface that hides the nature (table or
query) of the underlying database access completely.

(There is another case in which PgObject will be problematic: if SELECT's
using LIKE or regular expressions are used, indexes to an object entry
ala drug.['digi.*'] might fail.)

We could either extend gmPgObject or have an additional object/interface.
I will be happy to help in either case.
 
Hilmar