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
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
