Re: [Gnumed-devel] database abstraction

[Horst Herb]

Karsten Hilbert wrote:

> or the like. IOW, have an API for business logic. This isn't
> really concerned with underlying ways of how to actually
> access the data itself. That may happend directly, cached in
> multiple objects, cached in one large cache object,
> you-name-it-i-dont-really-care.

You can have it two ways:
- either you limit yourself beforehand to a few known situations, then 
the highest level of abstraction as you propose makes sense
OR
- the interface is fairly ignorant regarding available data, but it can 
handle whatever data is available and the interpretation is left to the 
user by default unless specific business logic is implemented on top of 
the rather low level "ignorant" data

Look at what happens to Java: their programmers get lost in the API 
jungle and don't even know any more where to ask for directions.
I do't want a humungous API for gnumed.

I expect the people writing the user interface to have some basic 
knowledge about the underlying database structures, and to use them 
accordingly. I thought gmPgObject is a reasonable way of at least 
relieving the burden of manually writing SQL queries for anything, and 
relieving the burden of following complex references would be 
comfortable enough, and higher levels of abstraction only neccessary in 
few exceptions.

Remember the law of the proportionality between stability of software 
and lines of code. Is KISS not in favour any more? The idea was having 
slim user interface clients communicating with the powerful backend. If 
you want a drug.interacts(drug2) (we all want it), you should implement 
it on the server side as stored procedure, and not in the client. Same 
is valid for all other examples like patient.pregnant() etc.

In any case: even if you chose to have very high level abstraction on th 
client side, you still need to have some execution of queries, some 
communication at some stage. whether you use gmPgObject directly or as a 
base class or as a mixin - I believe that it is as universally useful as 
gmPG is. Thus I think it should remain in python-common.

Maybe I am alone with my opinion here.I would appreciate opinions.

Horst