Re: [Gnumed-devel] vote on postgres interface

[Ian Haywood]

On Fri, Aug 09, 2002 at 08:39:19AM +1000, Horst Herb wrote:
> On Friday 09 August 2002 7:44 am, you wrote:
> 
> > PyGresQL: available in binary form for Linux and Windows, though the Linux
> > version seems neglected lately. Slowest adapter so far (?)
> 
> We have to come to a conclusion quick, since I am itching to continue my 
> database work and I don want to rewrite all adapter specific sections yet 
> another time.
> 
> Horst

Personally, I preferred the old library (whatever it was, I'm pretty
confused now, how many wrappers does one database need, anyway?)

listen/notify is essential to prevent booking collisions,
for example. 

However, we could regret leaving DB-API severely if we ever need to
switch databases (I admit I can't think why, Postgres aren't exactly
going to go bankrupt)

Humble suggestion: gmPG implements its own wrapper, say:

        query (service, string)
        async_query (service, string, callback)

The advantage is that in the future we need to make cross-service joins
(getting names and addresses from patient IDs will probably be most
common, but there are potentially many others)

gmPG could define another function, which would form a 'proper' SQL join
if
both services are on the same physical machine, and do a 'client-side'
join if they are not.

        def join (service1, table1, key1, where1, service2, table2,
key2, where2)


        On a single server this becomes
        "SELECT * FROM table1, table2 WHERE key1 = key2 AND where1 AND
where2"
 
On distributed servers:
        server1: "SELECT * FROM table1 WHERE where1"

then for each line so returned, a query is sent to server2:
        server2: "SELECT * FROM table2 WHERE where2 AND key2 = key1"

Ian

pgpjT9bx0Wyji.pgp
Description: PGP signature