Re: [Gnumed-devel] Comments on 0.2

[Tim Churches]

Syan Tan wrote:
> actually, it would be better if you did put input into the list. I made 3 
> arguments against
> 
> using hashing as a diffing technique, and really, only the last argument has 
> any 
> validity
> (mild complexity). The other 2 were bunkem ;)

No, they were useful comments and have stimulated various lines of
investigation (such as empirically measuring the cost of hashing a "row"
object via a has method in our middleware layer - no answer yet, but
we've learnt to always empirically measure computational costs and not
to assume something will be cheap or expensive when using Python - we
are constantly surprised - usually by the cheapness, but occasionally
something is much more expensive than it should be due to some
implementation detail in the guts of Python itself). Also, ours is a Web
app, and the network overhead even on fast connections is typically 300
or 400 ms - thus adding 5 or 10 to calculate and compare a hash is not
an issue, especially when it only has to be done when the Update button
is clicked, not for every interaction. The other consideration is that
although we really like PostgreSQL, we have been careful not to
completely lock ourselves into it (although we use OIDs, which was a big
mistake in retrospect...).

Tim C

> *On Sat Jun 24 20:23 , Tim Churches sent:
> 
> *
> 
>     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
> 
> 
> 
>     _______________________________________________
>     Gnumed-devel mailing list
>     address@hidden
>     <javascript:top.opencompose('address@hidden','','','')>
>     http://lists.gnu.org/mailman/listinfo/gnumed-devel
>     
> <parse.pl?redirect=http%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fgnumed-devel>
> 
>