[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Comments on 0.2

From: Ian Haywood
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Sun, 25 Jun 2006 06:39:04 +1000
User-agent: Thunderbird (X11/20060516)

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).

> [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
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 
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 

> 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 
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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]