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
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
