apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: [PATCH]: improved error reporting for apr_dbd_mysql.c - correct version
Date Fri, 19 May 2006 09:57:53 GMT
On Fri, 2006-05-19 at 01:01 -0700, Alex Dubov wrote:

> Now, before the error reporting problems evolves into
> discussion, here is my view of things:
> 1. Any db error kills the request (404 || 500)

I'm not sure how/why APU DBD relates directly to Apache error codes. DBD
can be used elsewhere as well. Don't assume people will use DBD under
Apache or even under mod_dbd only.

> 2. Error code goes to error_log as is

Actually, once the codes become APR error codes, logging will be taken
care of easily.

> 3. Current apr error numbers contain zero information

True. We need to define a new set or extend the existing one.

> I don't see any alternatives for this. Acting on error
> code involves knowledge of the backend quirks, so it
> backend dependent.

Of course there are alternatives. Current APR error codes are an example
of how it's done. If all databases we support via DBD have their set of
error codes, we only need to find a super set (i.e. union) that covers
all of them (or better, the ones we can encounter in native calls) and
return those code consistently. The caller can then reliably determine
what happened, regardless of the database in question.

So, it is the duty of the DBD layer to translate the "quirks" into
standard DBD behaviour. Otherwise, why bother? We can all just use
database specific APIs and be done with it.

> Saving backend dependend literal
> message to the log is just stupid (logs are meant to
> be automatically analyzed, especially db logs).

It is better not to come up with sweeping statements like this. It is
often useful, especially during testing, to have a human readable
message printed in the log in order to figure out what the problems is.

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

Which would then make, for instance, APR file API a bloat, I guess.


View raw message