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 (and question)
Date Fri, 19 May 2006 03:27:12 GMT
Quoting Alex Dubov <oakad@yahoo.com>:

> So, to do anything
> useful you must do something like:
> if(apr_dbd_pvselect(...)) {
>   err_code = apr_dbd_error();
>   ... backend specific stuff for err_code
> }
> Now, explain me how it is different from my way:
> if((err_code = apr_dbd_pvselect(...)) {
>   ... backend specific stuff for err_code
> }

You are returning a backend specific error code from an APU call.  
Current code apr_dbd_error() returns a description of the error -  
something that isn't likely to be used in any error processing (too  
ambiguous) - it is there as a human readable string that will most  
likely end up in the log.

We should be returning APR (or APU) error codes in all functions, so  
that the caller can verify what happened regardless of the underlying  
database. That's why the situation is suboptimal - we don't have these  
codes and we sure aren't returning them consistently.

An APU DBD API user may not even include any of the database specific  
headers in the code to figure out what they mean. Actually, the caller  
should not be required to do so - the layer should be database neutral  
as much as possible. If the caller is using a specific database for  
all work (and is sure of the presence of relevant headers etc.), the  
caller should get a native handle and fetch underlying specific errors  
from there, then process them accordigly. Or possibly even wrap up the  
APU DBD calls + fine grained native error handling into another set of  

However, returning such backend error codes from DBD directly is going  
to result in what we have now - inconsistent behaviour across drivers.

> 2. The problem with mysqld: say you access some db
> linked page for first time - apr-dbd opens connection
> to mysqld and all work fine. Say, 8 hours passed and
> nobody touched any db linked page on the server
> (development server after night). Mysqld already
> dropped the connection, yet apr-dbd thinks that
> connection still exists and fails with stupid error
> until the apache is restarted.

OK, get it. Have you tried using apr_dbd_check_conn() to figure out  
the status of the connection before going forward with queries? With  
MySQL driver, this should call mysql_ping(), which reopens the  
connection to the server.


View raw message