Re: [Gnumed-devel] Comments on 0.2

[Ian Haywood]

Karsten Hilbert wrote:
> On Sat, Jun 24, 2006 at 07:17:45PM +1000, Ian Haywood wrote:
> 
>>>         kwargs['patient_id'] = self.check_encounter_sanity 
>>> (kwargs['episode_id'], kwargs['encounter_id'])  # if an error, exception 
>>> goes straight to be caller, we don't need to handle
>> This could be folded into cBusinessClass too.
> No it cannot. But it can be folded into the cClinicalItem
> subclass of cBusinessObject since it is generic to all
> *clinical* item objects (clin_root_item children, that is).
Ok.

> [do this in 0.3]
of course.

>> CASE WHEN allg_type ~ '[0-9]+' THEN allg_type::integer ELSE (select id from 
>> clin._enum_allergy_type where value=allg_type) END
> How do you handle the error case ? You'll have a hard time
> finding out exactly what went wrong from the error
> information PG gives you. Did the user type in a bogus
> allergy type ? Did the programmer screw up (such as an
> off-by-one error) ? 

> 1) migrate to psycopg2
> - offers access to SQLSTATE error codes

AFAIK with SQLSTATE we can pick the difference between an integrity error, 
23503, (which is what
would happen if you entered a number which wasn't in enum_allergy_type.pk)
and a failure of the sub-select to return any values from a bogus string,
which resolves to a NULL, leading to "NOT NULL VIOLATION" (no 23502)
Obviously we will need to explicitly catch them and then re-raise a
custom GnumedError class with more sensible error messages.
(I didn't say exceptions mean *no* work, just less)
Hopefully we can do this in a generic way, so if an integrity error is
raised on any query, if we have not bothered to write a specific handler,
we scan the error strings for the names of the columns and raise
a GnumedError (column="foo", error=_("The value is invalid"))
then generic GUI layer code maps the column name back to the widget name, and
displays a message box referring to that widget.

However we don't need to catch and re-raise for programming errors, or
more importantly, when the OperationalError is from one of our own (possibly 
locale-specific)
backend triggers, which will have a nice error message to begin with.
This allows all sorts of fine-grained input checking, such as phone numbers,
Medicare numbers, etc., which Richard loves, in the database where such things 
belong.

> Also I am not sure whether PG rules
> allow this sort of dynamic runtime datatype fiddling.
They don't, it's a bit of a hack. allg_type is always text in the view, and is 
always
converted to an int for the real table. But not really, as the integer will 
move across
the network layer as a text representation anyway.

> - offers connection pooling (reduce gmPG complexity)
Can we pool write-connections now?

Ian