Re: [Gnumed-devel] Comments on 0.2

[Karsten Hilbert]

On Sat, Jun 24, 2006 at 08:06:52AM +1000, Tim Churches wrote:

> >>> Exactly what we do. We run serializable transactions. No
> >>> bullshit in our database.
> >> Yeah, and you can set that behaviour as a config option in PG...
> > But we cannot rely on it being set to on. That would be like
> > relying on MySQL having InnoDB table by default. Hence we
> > set this behaviour whenever opening a new connection. Which
> > is unrelated to whether we need "select for update".
> 
> Karsten, I think it is OK to say: "GNUmed only works correctly if you
> configure it this". Trying to code for all possible misconfigurations
> will drive everyone mad and lead to bloated, overly complex code
Tim, I think you are talking about a non-issue here without
having looked at the code in action.

Whenever gmPG.ConnectionPool.GetConnection() is called it
either returns a pooled (read-only) connection or a brand
new read-write connection. Either way it is preconfigured
with regards to serialization, timezone handling and
encoding. The user of the connection doesn't have to worry
one bit about it. I don't have the faintest clue why people
would complain about this behaviour.

All this is unrelated to why I initially thought we'd need
"select for update", *too*. I start seeing now that maybe we
don't need it. Even if we do it is hidden away just as well:

an allergy to penicilline has been confirmed to exist, so
change it's status:

 pat = gmPerson.gmCurrentPatient()
 emr = pat.get_emr()
 allergies = emr.get_allergies()
 for allergy in allergies:
   if allergy['substance'] == 'pencilline':
     allergy['definite'] = True
         allergy['narrative'] = allergy['narrative'] + '; lab-confirmed'
     success, data = allergy.save_payload()
         if not success:
           print "an error occurred:", data
           print "what we saw   :", allergy.original_payload()
           print "our changes   :", allergy.modified_payload()
           print "database state:", allergy

Where in freaking hell is this any more complicated than it
needs to be ? All the concurrency detection is handled
behind the back of the user by the base class of cAllergy
(as returned from get_allergies()).

Of course, all of the code needs refinement to let the user
make a decision about what to do with the conflict.

> At some point you need to trust  sysadmins
> installing the system to follow instructions, or better, to provide
> automated installation tools and trust those installers to get the
> configuration right.
People have likewise complained about our installer being
complicated on account of it trying to get it right.

> Fair enough, but remember that one certain way to ensure that no crap
> enters the database is to fail to deliver a production-ready V1.0 in our
> lifetimes. You need to find the right balance between theoretical
> perfection and achievable and sustainable levels of complexity.
Sure enough and I really wish people would help find it
(such as with the recent "select for update" discussion).

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