DevelRefMisc (Miscellaneous development reference)

AuditTrails

Data entry: concurrency conflict resolution

  • see this post for more information
  • rows should not be locked during user interaction
  • clients must check for changes to the data before submitting updates
  • also see the docstring in the gmBusinessDBObject.py module
  • this thread is of interest, too
  • the last article (Using SELECT FOR UPDATE) in this PostgreSQL General Bits issue sums up the general concept
  • this is what we do in the middleware business object base class and why:
    • select for update
      • whenever I want to make sure I can safely write to a row I must do select for update on that row
      • this will prevent other transactions from writing to that row until I release that lock by commit
    • checking XMIN
      • after my select for update no one else can write that row until I commit
      • therefore, the timespan between select for update and commit should be minimized
      • therefore I only select for update right before actually writing
      • however, the user has seen data on screen from much earlier, namely when the initial, simple select was done
      • other people might have overwritten that data in the database in the meantime (yes, I have seen it happen)
      • they, too, properly locked the data but the lock is released again because they already finished their write
      • now I want to write my changes to the backend
      • if no one else has locked the row I can do that regardless of what is actually in the database right now
      • that way I could overwrite other people's interim changes without ever knowing they existed
      • this is unacceptable
      • therefore I check XMIN before I write to the backend
      • it must be the same XMIN value as when I initially read the data
      • or else someone has overwritten the data in the meantime
      • XMIN is a PostgreSQL internal "timestamp" telling me who last modified a given row
      • if XMIN changed between me reading/displaying the data and me wanting to save changes I know someone else modified it
      • at which point I need to inform the user about that fact

Data importers API

all importer modules in client/importers define two functions

accept_file (file)

this makes a Python file object, and returns - True: I successfully imported this file (unmatched patients don't mean unsuccessful) - False: I don't recognise this format, try another importer - exception: I recognise the format, but there is a serious problem (corrupted file or database error)

and if this is a results format: manual_match (person, fragment) - person is a gmPerson object - fragment is the file-fragment of unmatched data saved in lab_result_unmatched again, returns True/False/exception as above

Then, Gnumed can respond to file drag'n'drop events (stupidly easy in wxPython), and try to import it. (plus a command-line version to run from procmail, fetchmail &c) If no importer recognises it, we can pop up a dialogue to add it to the docs server as an "opaque" file.

See also ImportersCountrySpecific

Data Types - Character fields

Use type TEXT on character fields

  • I have begun a habit of using type TEXT on all the character fields I come across in the database. Char(n) and varchar(n) are handled the same in PostgreSQL PLUS they require an additional length check. Now, this length check is desirable when there absolutely never ever will be any alternate length string being put into a given field but I harbour the fear that the minute we put down such a restriction we'll find a case where id doesn't apply. Now, the length of a US SSN won't change tomorrow but we don't have a field specific to the US SSN. And I am not aware of other fields specific to a string of defined length for that matter.--- Karsten http://mail.gnu.org/archive/html/gnumed-devel/2004-05/msg00156.html
  • another thing to be aware of its that if you use varchar and dump the db, pg_dump writes character varying in place of varchar

Default values where applicable, use 'xxxDEFAULTxxx'

  • As a choice for default value, '__default__' would be a poor carryover from Python because '_' has a meaning in LIKE queries, as would be '***default***' since '*' has meaning in regular expressions. Options considered included '>>>default<<<' and settled on Hilmar's suggestion 'xxxDEFAULTxxx' --- Karsten http://mail.gnu.org/archive/html/gnumed-devel/2004-01/msg00030.html

Layout managers
  • There are presently two layout managers from which to choose
  • The code makes it easy for you by preselecting the one that is actively being worked on.
  • If you really want to use the other you'll have to deliberately change that choice and be prepared to handle bugs.
  • The one that's called "status_quo" in the config tables is the "default", it is the one that comes closest to Horst's original design (eg. the tabbed notebook with plugins) with more and more designs carried over from Richard (eg vaccination, allergies, edit areas). It is often called Horst-space in contrast to Richard-space (itself backgrounded in Richard's GUI whitepaper - see DevelopmentReference.

LDAP

Null values vs clinical "negatives"

Web Client

A primordial web client is at
http://publicdb.gnumed.de:8080/gnumed-test-war
user: tomcat , password: tomcat note e.g. on finding Kirk, you must click the "clinical" hypertext link to access clinical functions
gnumed-devel posts at

White Papers

Whitepapers:
  • White Papers in CVS:
    • readable via web browser... simpy open a paper, and click the "as text" link. * include:
      • Database architecture overview
      • Distributed database services including personalia
      • Interacting with the backend
      • Internal messaging and signal dispatching
      • List of available signals/messages
      • Appointment book
      • Login screen, overview
      • Pharmaceutical Reference Browser
      • Code browser
      • Prescription dialogue
      • Python shell (the one and only)
      • Interactive SQL Window
    • errata:
      • user/_user privilege separation had been required, but has since been abolished
        (July 17, 2004 - see here)
  • future web site considerations
Topic revision: 11 Feb 2011, SebastianHilbert
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark