gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] middleware upgrade


From: Karsten Hilbert
Subject: [Gnumed-devel] middleware upgrade
Date: Wed, 21 Dec 2005 12:40:54 +0100
User-agent: Mutt/1.5.11

On Wed, Dec 21, 2005 at 08:50:45AM +1100, Ian Haywood wrote:

> > I am absolutely with you here. It dawns on me that this is
> > part of the reason why you want "our own" DB-API adapter ?
> The new wire protocol does allow richer error messages, yes.
It really is a shame that none of the DB API adapters
supports the new wire protocol sql error code handling yet.
Except psycopg includes it in the error message itself
exactly so that it is parseable until they find a better
solution. They also have listen/notify now working.

Any time I look at psycopg I feel very good about it again.
Better than any of the other adapters. I don't feel that
good about my own middleware code, even. Usually I am faring
quite well relying on that feeling. I have felt that good
about Python, too, when I first saw it. Same with
PostgreSQL. Not entirely so with wxPython. Much so with
Debian Sarge or apt in particular.

I do feel like we should move to psycopg if we move to new
middleware. We should then write unit tests for it, too. In
a way there *are* unit tests for it although they are not
formalized. One would expect that all python code in
examples/ works flawlessly which tests a few things.

> If you want to respond specifically to want the backend has done
> you need to scan the string. I noticed in one of Sebastian's
> posted logs how this breaks badly: your error messages are in German.
Yes, Suse thinks it's a good idea to set a locale for user
postgres. Which is a stupid idea.

> The new error messages include a code number from a set list
> (http://www.postgresql.org/docs/8.1/static/errcodes-appendix.html)
> solving this problem.
None of the adapters give access to that yet, though. Also
because there's no provision for it in DB-API 2.0.

> > Even though it makes my heart blead:
> forgive my nitpick: you mean "heart ache"
> A bleeding heart is an either: 1/ sarcastic sympathy for someone else's
> misfortune, 2/ an political insult referring to those who
> wish to use taxpayer funds to help the less fortunate (and so rarely heard 
> outside of USA)
Thanks. I should spell correctly, too: "bleed".

> > a) pl/python isn't really that well supported (there is no
> >    trusted version thereof)
> It's been in postgres as long as I can remember (5+ years)
> Trusted support was taken away on the advice of python developers
I know. The "problem" with this is that in that case
bootstrapping (functions) will have to be done by a database
superuser and cannot be done by gm-dbo anymore. We could,
however, have "postgres" bootstrap the functions only or
temporarily grant superuser status to gm-dbo for function
creation.

> > c) despite any of the above it'll become *extremely*      
> > difficult to write the needed code as it is quite      
> > dependant on locale setup and a million other things that   
> > are unlikely to be properly set up on a server, let alone
> > for the postgres system account under which the postmaster runs
> find_patient (search_string, search_locale) ;-)
> 
> but point taken.
Yep, you yourself pointed to one potential problem: error
messages will change.

> > All this happens in real time on a single patient EMR
> > concurrently *every single day* I work.
> That's interesting. Our current package (the AU standard -
> Medical Director) simply locks you out of a record if it
> is open on another client.
Our less well written packages do that here, too.

> It gets better: if the client then crashes (not exactly
> rare), leaving a stale lock, you need to reboot *the server*
Well, but that's a server problem. PostgreSQL would simply
close down the affected backend process.

> Now do you know why Richard is tearing his hair out for a
> working client? ;-)
Now do you know why I want to make locking as fine-grained
as possible and why I go to such great length with all this
XMIN and "select for update" business ? ;-)

Because I want to give you guys this benefit.

> I have toyed with the idea of having a per-client set of updateable
> views, on top of the 'business' views, thus enforcing 1:1 correspondence
> with GUI elements.
Well, in that scenario you'd have to make all the "business
views" be updatable/insertable. Or else you'd have to tell
your "dumb" business objects where to dump which data to.
And if the views are updatable and written to you'll have to
invent some formalism for the xmin handling as you may end
up with xmin values for several underlying tables in one
view. (Of course, I had to solve that, too.)

There's also the problem of how to act when joined-into-the-view
tables need an insert while the "main" table needs an update ?

These problems might be solvable by using stored procedures
for each business view for update/insert/delete. That would,
however, only move the middleware coding into the backend -
the same code was previously in the middleware we currently
have. It would also raise the question of granularity again
- how much work is each stored proc to do ? One might feel a
need for a stored proc for each combination of possible
input parameters which would make the number of procs
explode. Remember that stored proc call signatures are not
dynamic as they are in Python itself. That is the very
reason why the current middleware uses the paradigm:

- a business object instance represents an *existing* backend object
- create_*() only does the minimum necessary
- all other fields are handled through the then-existing business object 
instance

> When you instantiate a GUI element, you simply give it the name of a
> backend table/stored procedure via wxGlade. No client-coding at all, other 
> than making the widgets
> generically data-aware, plus our 'special" widgets such as the phrasewheel 
> and the SOAP box.
See above. But hey, if you have working code, I am all for it.

> You hold client state, such as the current patient, using a temporary table.
The advantage of holding some state in the client is that
that state automagically goes away when the client dies.

> > *So far* it pretty much is  :-o
> [picks jaw up off the floor]
> You've read the code, haven't you?
Yes.

> I'll start grafting then
I am looking forward to the result. I would set a target for
0.3. Perhaps looking at psycopg is worth it.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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