[Top][All Lists]
[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
purepg.py
Description: Text Data
pgp3wwjP5DhoG.pgp
Description: PGP signature
- Re: [Gnumed-devel] A question re demographics, (continued)
- Re: [Gnumed-devel] A question re demographics, Jim Busser, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Karsten Hilbert, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Karsten Hilbert, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Ian Haywood, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Karsten Hilbert, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Horst Herb, 2004/07/19
- Re: [Gnumed-devel] A question re demographics, Karsten Hilbert, 2004/07/19
- Re: [Gnumed-devel] A question re demographics,
Ian Haywood <=
- Re: [Gnumed-devel] A question re demographics, Sebastian Hilbert, 2004/07/20
- Re: [Gnumed-devel] A question re demographics, Horst Herb, 2004/07/20
- [Gnumed-devel] Mistaken Patients - PNG enclosed, Richard Terry, 2004/07/20
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Karsten Hilbert, 2004/07/20
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Richard Terry, 2004/07/20
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Karsten Hilbert, 2004/07/20
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Jim Busser, 2004/07/20
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Karsten Hilbert, 2004/07/21
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Elizabeth Dodd, 2004/07/21
- Re: [Gnumed-devel] Mistaken Patients - PNG enclosed, Karsten Hilbert, 2004/07/21