Re: [Gnumed-devel] database abstraction

[Hilmar Berger]

> 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

I believe that *both* types of an interface are needed in gnumed. The
higher level objects will be used by the frontend and will in turn use the
lower level interface. No need to go in only one direction, IMHO.
Surely, high level interfaces are more limited. But that does not pose big
problems, since they are designed to just do only a specific task. I like
to think of this interface levels as starting points for every higher
level task. If the given interface is not sufficient, you can still derive
your own interface or extend it or even start from one level below. It's
something like using high level languages to code a project: you still
have to know *some* details of the implementation, but you surely wouldn't
like to miss, say, the high level data types of python only because the
are limited in their abilities. 
 
> 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.
We might need some control of what interfaces are populating gnumed, but
that should be possible given the existence of our admins :).
 
> 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.
I don't completely agree with that. IMHO gmPgObject is a reasonable
interface, but to me it is just the first step. I don't consider higher
level interfaces an exception - I suggest using them whereever performance
is not hit too much. I believe that developers are just human beings, and
humans usally adhere to simple interfaces. To me, KISS means just that:
simple, reliable interfaces hiding the details of an implementation.
 
> 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.
Agreed, we can do a lot of those stuff at the server side. I would - and
will - do that once I have sufficient knowledge how to implement it (I
don't know much about higher level postgres programming until know). But
higher level interfaces will pay off even in that case - being stable
whatever happens beneath. 
 
I would prefer the following timetable (at least for me): 
1. implement the higher level API for the Drug Browser frontend
2. move the mid-level abstractions (parts of gmDrugObject, others) to the
backend side while the higher level API's stay as they are

BTW, does gmPgObject know about SQL-views and all that higher-level SQL of
which I still don't have the slightes idea :) ?

Hilmar