gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] database abstraction


From: Horst Herb
Subject: Re: [Gnumed-devel] database abstraction
Date: Fri, 25 Oct 2002 07:17:07 +1000
User-agent: KMail/1.4.7

On Fri, 25 Oct 2002 03:14, Hilmar Berger wrote:
> BTW, does gmPgObject know about SQL-views and all that higher-level SQL of
> which I still don't have the slightes idea :) ?

views are entirely transparent - from the client side perspective they are 
just another table. On the server side you need to write some rules to allow 
views to be updateable in the same way as a table, but that's all.

Look at the "basic_person" and "basic_address" views which denormalize a lot 
of normalized tables for convenience's sake in that they pack the most common 
"combinations" into a single pseudo-table (view).

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.

When you have a table like a person's identity, referenced by tables 
containing a person's name, a person's address etc and you don't have to 
worry anymore about these because you can access them via 
person.address['home'] or person.name['maiden'] it comes close to the 
expectations of Karsten, but it doesn't require extra configuration or coding 
regardless of the table content, because gmPgObject parses the metadata and 
constructs these objects for you. It doesn't cost much performance since the 
parsed metadata is cached and the relevant tables are only accessed at the 
time when the data is accessed via the object - meaning most queries will 
never even be sent to the backend.

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.

Of course, to achieve all this, there is still a lot of work to do, but the 
foundations for this are laid, there are no technical problems, just 
straightforward continuation of the implementation

Horst




reply via email to

[Prev in Thread] Current Thread [Next in Thread]