[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 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)
That is why I want SQLSTATE handling if we are to try to do
better.
> Obviously we will need to explicitly catch them and then re-raise a
> custom GnumedError class with more sensible error messages.
yes
> 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.
Absolutely.
> 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.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- Re: [Gnumed-devel] Comments on 0.2, (continued)
- Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/23
- Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/23
- Re: [Gnumed-devel] Comments on 0.2, Tim Churches, 2006/06/23
- Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Ian Haywood, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Ian Haywood, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Ian Haywood, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2,
Karsten Hilbert <=
- Message not available
- Re: [Gnumed-devel] errors and middleware (was 0.2), Ian Haywood, 2006/06/24
- Re: [Gnumed-devel] errors and middleware (was 0.2), Karsten Hilbert, 2006/06/24
- Re: [Gnumed-devel] errors and middleware (was 0.2), Karsten Hilbert, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/24
- Re: [Gnumed-devel] Comments on 0.2, Tim Churches, 2006/06/24
Re: [Gnumed-devel] Comments on 0.2......................., Sebastian Hilbert, 2006/06/19
Re: [Gnumed-devel] Comments on 0.2, Karsten Hilbert, 2006/06/20
Re: [Gnumed-devel] Comments on 0.2......................., Syan Tan, 2006/06/19