[Top][All Lists]

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

Re: [Gnumed-devel] Comments on 0.2

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Sat, 24 Jun 2006 23:09:23 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Sun, Jun 25, 2006 at 06:39:04AM +1000, Ian Haywood wrote:

> > [do this in 0.3]
> of course.

> > 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)
That is why I want SQLSTATE handling if we are to try to do

> Obviously we will need to explicitly catch them and then re-raise a
> custom GnumedError class with more sensible error messages.

> Hopefully we can do this in a generic way,
yes, I hope so, too

> 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"))
Sounds good ! :-)

> then generic GUI layer code maps the column name back to the widget name, and
> displays a message box referring to that widget.
I would suggest doing *that* part the other way round: Have
the GUI tell the error display the custom message to display
in addition to the error itself.

> However we don't need to catch and re-raise for programming errors,
Well, programming errors should abort the program, so, yes
we don't need to catch them. But, yes, we *do* have to catch
them so we can a) *gracefully* abort and b) log the error.
However, this should definitely be doable entirely generic.

> 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.
That'd be nice. We'll have to work out exactly where to
handle which level of detail of checking but, yes, that's
IMO the general idea.

> > 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.
Nope. SQLSTATE requires the v3 protocol. Which in turn
transfers parameters out-of-band (IOW, in binary in parallel
to the query itself). Which we want for protection against
SQL injection attacks *anyways*. Even if at the end of the
day v3 *does* transfer in text eventually this does not mean
we have access to that text representation at any level.

> > - offers connection pooling (reduce gmPG complexity)
> Can we pool write-connections now?
Oh, you can even now if you implement your own pooling. In
fact, our pool did not ever really *pool* connections in the
standard sense. What it did was to *share* read-only
connections. Which is only safe for read-only. Which is why
read-write was not shared until now.

But, yes, write-pooling would then be possible. However, one
may need to be careful about encoding issues.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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