Quoting Alex Dubov <[EMAIL PROTECTED]>:
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
functions.
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.
--
Bojan
