gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Specs (was: Gnumed brochures)


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Specs (was: Gnumed brochures)
Date: Tue, 20 Dec 2005 00:47:52 +0100
User-agent: Mutt/1.5.11

On Mon, Dec 19, 2005 at 07:42:05AM +0800, address@hidden wrote:

> > > So, Richard and I need to write our own frontend
> > This is excellent. What sort of backend does it use ?
> None at present, it's an "empty shell" to experiment with data-entry
> techniques.
Ah, good. I always knew Richard (T) is good in that sort of thing.

> That's the problem. Each layer of the stack has to handle errors
> of the above layers, imposing is own conventions and rules, and often
> losing information, so by the time we get to the UI layer
> often all we get is True/False.
Hm, OK, I see.

> You style would be tolerable if we had a common style,
I am all for common style !

> and
> everywhere functions return (True, value) or (False, (error_code, 
> error_message))
Sure, I am with you on that !

> I would really like to be able to propagate an error message (in some 
> circumstances) right from a locale-specific backend trigger (say
> checking the HIC provider number is valid) to the user dialog.
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 ?

> True. But 90% of the time errors are one of two things
> - a bug in the program (either backend or frontend)
> - hardware disaster, such as the backend server going down
You are probably correct.

> In this circumstance the only sensible action is to pop up an error 
> message and abort the action.
Yep, sounds about right to me.

> This can be solved once using a specific exception class (say FatalError)
> and a single catcher at the top of the stack in UI code.
OK, sounds fair.

> Sure, 10% of the time you want to take specific action in response to 
> non-fatal
> errors (such as consistency violation)
> 
> In that case you can either do
>
> flag, val = foo ()
> if not flag and val == MyNotFatalErrorCode:
>    some specific error stuff
>    return False
> 
> all the time
> OR
> 
> try:
>    foo ()
> except MyNotfatalError:
>    some specific error stuff
>  
> which is just as readable and easy, that 10% of the time.
I agree.


> > > l = sql.find_patient ("Smith") # runs the backend prepared query
> > find_patient, returning row instances
> > Very hard or impossible to do sanely because find_patient()
> > requires extensive and intricate munging of input which
> > PostgreSQL *does not even support properly yet* !
> IMHO this (excellent) code belongs as PL/Python.

Even though it makes my heart blead:

a) pl/python isn't really that well supported (there is no
   trusted version thereof)

b) pl/python is not part of core and hence an additional
   dependancy

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

In fact, it would be counterproductive the set a certain
locale for that user as it would affect a whole slew of
other DB things - database encoding, collation rules,
timestamp formatting. Let alone having other databases
hosted on the same server but needing other locales ...
PostgreSQL does not yet support enough of the
collation/locale functionality at the needed granularity
(column level, that is). And what it does have is flaky in
some places. For the record: no other OSS DB has it, either.

So, no, locale munging is to be done on the client side for
the time being.

BTW, I'd love to be proven wrong on a), b), and c).

> When I first wrote to Horst Herb, way back in medical school, and he told
> me to go and read about this "postgres" stuff, our understanding was we
> would have a "smart server, dumb client" model, with heaps of stored 
> procedures doing all kinds of fancy stuff
I am much inclined to put more logic into the backend, no
problem with me.

> > > a = p.allergies # runs select * from allergies where fk_patient = <pk of
> > patient>, which is cached
> > 
> > *** How do you evict the cache when the backend changes state ? ***
> How do we now?
We evaluate NOTIFYs.

> Sure, we check for consistency using xmin when we commit data (that's easy to 
> add to my model)
OK, good.

> The other thing is reloading cached tables in real-time based on NOTIFY 
> events.
> IMHO this is a classic case of over-engineering. Where is the use-case?
> Two doctors can't see the same patient at once!  
Sure, that's the rare use case. The way more common use case
is refreshing of the frontend. We are routinely adding data
to one single patient every single day concurrently at both
of the practices I work. Front desk staff is printing forms
while I still enter consultation notes or work up that last
form to print or whatnot. Or they are setting up the next
appointment. Or entering that repeat script the patient
didn't tell me about. Or sign out the xrays I handed to the
patient. Or scan in the lab work that just came back.

All this happens in real time on a single patient EMR
concurrently *every single day* I work.

> > p.update() isn't needed as the current middleware persists
> > data when something() is called.
> That's actually a feature ;-)
I know.

> What Richard wants is a big fat "Save" button, and everything done to that 
> point gets committed when and only when you press it.
I am fairly OK with that behaviour, actually.

> The main motivation is commits are going to take 3-4 sec on our primitive 
> Anglo-saxon hardware,
No they won't but that's not a counter-argument.

> This way allows both styles.
Yes, I agree.

> > Should we try to write a class which inherits from
> > business/gmClinItem.cClinItem() or even
> > pycommon/gmBusinessDbObject.cBusinessDBObject() but
> > generically provides your proposed interface ?
> That's basically want I'm after: a 'plain-vanilla' business object
> for the 90% of the time when we *don't want* extra specific client 
> functionality, because (perhaps using views and other postgres magic) we can 
> achieve 1:1 correspondence between business and backend object models.
OK, I was in fear I would be going overboard with putting
business logic into the backend if I did that but, hey, if
people agree, fine with me. After all, it's just views which
are plentiful and volatile by definition (IOW, can be
changed on the fly even within a running and deployed
database instance).

> > It doesn't make sense to implement/maintain another DB API adapter.
> Initally I thought I had to do it this way, the main motivation is speed
> (it can do prepared queries with 4 packets and one wait-state, yes this
> does matter (to me)).
> However I now realise there's no reason this idea can't be grafted onto
> the standard adapter, which I'm happy to do in the unlikely event the
> use of purepg is your only objection. ;-)
*So far* it pretty much is  :-o

I should definitely like to see what comes of it if you
graft that idea on one of the DB API adapters available in
Debian. If you *really* are that desperate for speed please
do test and consider psycopg (given it supports LISTEN/
NOTIFY). I am not wedded *that* much to pyPgSQL.

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]