Re: [Gnumed-devel] catching errors in an app

[J Busser]

At 8:46 PM +0100 2/16/06, Karsten Hilbert wrote:
> Ha ! Do you think we should add check constraints on some
> such fields ? IOW "unlimited" length is fine but no CR/LF/FF ?

Not sure. Some postal systems do have strict requirements that 
specify, for each address "part", the line on which the part should 
fall as well as the sequence within a line. So that purpose would be 
served by such a constraint.

My biggest question/concern probably has to do with importing, for 
example porting data over from a legacy system. When importing data 
that would normally violate a constraint, would the owner have all of 
the following options and are any inherent in postgres or would they 
have to be especially programmed?

1. when importing patients' demographics, can just the "bad" 
records/lines be streamed to some kind of log file while accepting 
the "good" records, or must it be "all or none"? I recognize that for 
whoever would have to fix the "bad" lines, it may be undesirable to 
second-stage import "just" the bad lines that have been fixed. 
However if the number of "bad" records is small, it may be less work 
to just key them in new, inside GNUmed.

2. if it is desirable to be "all or none" because (for example) it 
may be attractive to fix the records in the legacy app before 
importing them, can the "bad" records be easily identified, say, in a 
log of some type? Depending on the number of affected records and the 
complexity of the violations, the owner could better decide whether 
it is worth trying to adjust the violations programmatically, or to 
just fix them by hand.

3. or can constraints be turned off (even selectively, so that some 
constraints still apply), in order to tolerate the impurities? The 
constraints would then be turned on for normal business in GNUmed. I 
don't know if this would require that the tables be "ALTERed" before 
and after or if there is a "switch" definition that would achieve 
this during the import.
---> I know Karsten may cringe at this question (though I suppose it 
is interesting technically just to know the answer). But what I am 
thinking is that there may be records (patients) who are no longer in 
the practice, in whose data there is not the same value 'cleaning". 
So if for example the consequence would appear when trying to print 
an envelope, would people rather have their office/surgery staff 
repair the data at the time of the problem?

Maybe #2 is the best approach, but it is helpful to know the pros and 
cons including feasibility of the other options. The ability to a 
particular installation of GNUmed to accept some data impurity would 
be no adverse reflection on the purity of design. It is not a basis 
to "forbid" anyone to do something that is in their control. But the 
collaborative/social consequence of deviation would be for some 
GNUmedders to contribute help requests or problem reports that may 
not have needed to exist. *This*  IMO would be a basis to ask people 
to conform to desired methods.