Re: [Gnumed-devel] simplified GUI <-> database interaction

[Hilmar Berger]

On Sun, 13 Oct 2002, Horst Herb wrote:

> 2.) All these queries communicate almost always directly with the backend: my 
> analysis found that caching data really only makes sense for demographic 
> details of the cuurrent patient. The other execption are "patient 
> independend" list objects like a post code selector, but that is taken care 
> of the "OnDefault" option (which would not update this widget when a new 
> patient record is opened)
> We completely do away with complex data mapping, data abstraction and 
> intermediate caching layers otherwise. If we don't, I found that performance 
> suffers instead of the intended improvement.
> 
> Drawback is that query results have to be mapped manually for each result and 
> widget - but that is not as bad as it sounds.

I'm sorry, but can't completely agree with that ideas. I believe that we
would loose a lot of the benefits of a high-level object oriented language
if we have to do all backend communication 'by hand'. Hiding
implementation features in hierarchies of objects has certainly a
perfomance cost but simplify coding a lot. If, however, the costs to
access two or three performance-optimised objects in between the GUI and
the backend has that high an assigned cost that performance will suffer a
lot I would rather suspect that Python is not the langugage of choice to
code a project like gnumed.  

How high are the performance hits you have found ? What is the part of the
abstraction layers having the highest perfomance costs ?
Are you sure there is nothing we can do to keep at least a minimal
abstraction layer ?

Hilmar