[Top][All Lists]
[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
- [Gnumed-devel] database abstraction, Horst Herb, 2002/10/23
- Re: [Gnumed-devel] database abstraction, Hilmar Berger, 2002/10/23
- Re: [Gnumed-devel] database abstraction, Karsten Hilbert, 2002/10/24
- Re: [Gnumed-devel] database abstraction, Horst Herb, 2002/10/24
- Re: [Gnumed-devel] database abstraction, Karsten Hilbert, 2002/10/24
- Re: [Gnumed-devel] database abstraction, Hilmar Berger, 2002/10/24
- Re: [Gnumed-devel] database abstraction,
Horst Herb <=
- Re: [Gnumed-devel] database abstraction, Karsten Hilbert, 2002/10/24
- Re: [Gnumed-devel] database abstraction, Hilmar Berger, 2002/10/25
- Re: [Gnumed-devel] database abstraction, Horst Herb, 2002/10/25
Re: [Gnumed-devel] database abstraction, Hilmar Berger, 2002/10/24