apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Dubov <oa...@yahoo.com>
Subject Re: [PATCH]: improved error reporting for apr_dbd_mysql.c - correct version
Date Fri, 19 May 2006 08:01:09 GMT
I'm sending now a correct version of the patch
(yesterday's one contains error and misses

This patch, apart of error handling, introduces
support for unsigned types (needed to prevent "data
truncation" errors in some cases) and some general

For convenience, I've attached my full version of
apr_dbd_mysql.c. It's smaller than patch it makes
against Nick Kew's original.

Now, before the error reporting problems evolves into
discussion, here is my view of things:
1. Any db error kills the request (404 || 500)
2. Error code goes to error_log as is
3. Current apr error numbers contain zero information

I don't see any alternatives for this. Acting on error
code involves knowledge of the backend quirks, so it
backend dependent. Saving backend dependend literal
message to the log is just stupid (logs are meant to
be automatically analyzed, especially db logs). And
last, if you'll make apr-dbd completely backend
independend, generic action supported db connectivity
solution it will turn into ODBC style bloat - so why
not use ODBC in the first place.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
View raw message