gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] A question re demographics


From: Ian Haywood
Subject: Re: [Gnumed-devel] A question re demographics
Date: Tue, 20 Jul 2004 08:55:39 +1000

On Mon, 19 Jul 2004 23:01:10 +1000
Horst Herb <address@hidden> wrote:

> Downloading large binaries is tricky - since it involves a single Python 
> call, 
> and with Python threads there is nothing to gain because it would block all 
> other threads!
In this case, we really need a postgres client library to support async queries 
properly.
AFAIK pyPgSQL doesn't, nor do the others.

What we really need is a postgres library to use the wxSocket () interface, 
this allows
it to ask for a wxEvent every time data comes in from the network. This data is 
added
to a buffer, if it is an incomplete row, it returns straightaway.
If a complete SQL row has been received, it calls the associated callback for 
the query.
Despite Sebastian's advice, I have experimented with the postgres wire protocol 
in Python,
it really not hard at all. I attach an afternoon's work.

The problem is all of our middle and frontend code currently assumes 
synchronous queries.
The middleware API would have to change to pass a callback in, which is then 
called when the data arrives.
Obviously this is all post 0.1 (hell, so should patient photos anyway, is 
anyone really snapshotting all their 
patients today? ) 
> However, for compressed patient images of reasonable size I found no 
> perceivable delay within a local network.
> It is worth noting that for some reason a PyPGSL.PgSQL BYTEA data type 
> appears 
> to occupy MORE bytes than using Python's binascii.hexlify() function, and the 
> latter appears to work faster too. This completely baffled me - but it 
> becomes obvious when looking at the source code: non-printables are escaped 
> with 4 bytes, NULL characters even with 5 bytes, and several other special 
> cases involving quotes and slashes using multiple bytes for encoding. 
Is this backend storage, or transmission?

Anyway, surely base64 encoding is more efficient?

Ian

-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

Attachment: purepg.py
Description: Text Data

Attachment: pgp3wwjP5DhoG.pgp
Description: PGP signature


reply via email to

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