gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Comments on 0.2


From: Tim Churches
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Sat, 24 Jun 2006 20:23:36 +1000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

Karsten Hilbert wrote:
> 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).

OK. Since I don't have the time or inclination to study the GNUmed code,
 I'll refrain from making any further posts to this list. Best wishes
with the project, and I really hope it reaches some form of fruition one
of these days (or years, or decades).

Tim C





reply via email to

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