Re: [Gnumed-devel] Default values... use 'xxxDEFAULTxxx'

[Karsten Hilbert]

xxxDEFAULTxxx was eventually suggested by Hilmar, btw.

This mainly concerns some few fields in the database.

> i) it had been stated that the earlier source code needed to be fixed 
> (updated to accord with this convention) - I imagine this is either not 
> easy to do acros all of the existing modukes and/or not of sufficient 
> importance to warrant hunting it down.
Done.

> ii) ... are there character fields (or fields of other type) which will 
> be unable to hold a string of that length, yet which warrant some 
> (other) default conventions
I have made 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 valid 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.

> iii) ... there had been discussion of being able to record 
> unambiguously a distinction between:
> a)  "it has never been asked" = "no-one knows if it has been asked"
> b)  "the question was asked but the patient doesn't know, and/or no 
> collateral is believed to exist"
> 
> Would iii) be solved by using a NULL value for a) where, if a value is 
> entered by mistake, the field value can be reverted to null or is the 
> rule in PostgreSQL "once a value, always a value"
I think we haven't really come to a conclusion on how to
handle that. It was suggested to have the base class (or a
mixin) for input widgets provide values for the various cases
of "unknown". One area where I thought the above important
enough to go ahead and try some implementation was allergies
where we have the allergy_state table (which isn't used
anywhere, however). The rationale was like this:

- If the patient has known allergies there are rows in allergy.
- If there are no rows in allergy that can have any number of
  reasons.
- If we asked for allergies but none were elicited we have no
  way of recording that fact (in a processable way) if we only
  have the allergies table.
- So, any patient *must* have a row in allergy_state.

It could be taken further to make the client display a modal
popup whenever the "no row in allergy_state" state is detected
(or, given the below values, when has_allergy is NULL).

The allergy_state.has_allergy column can hold the following
values:

- NULL: unknown, not asked, no data available
- -1:   unknown, asked,     no data obtained
- 0:    known,   asked,     has no known allergies
- 1:    known,   asked,     does have allergies

Does that make sense ?

Suggestions welcome.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346