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