I'm finally starting to hack away at Nick's new DBD API for APR, and have noticed a few things about the API, which I have talked with Nick about on IRC. And would like the thoughts of others.
One is a capabilities function in the driver API, to provide a way for the application to figure out what features the driver does and does not support. (ie. Transactions, Prepared Queries, etc..).
nick's quick prototype idea was apr_dbd_capabilities(driver, APR_DBD_HAS_TRANSACTION);
The other thing I noticed was the lack of standardized return codes from the functions. Most of the function return error codes from the DB layer. It would be better to create a set of standard error return codes and map them into the APR error space for DBD, so each driver will return a standard set of errors to the application. This list of errors, however, will have to be thought out well though. As I know that the libdbi error set is very limited to be useful.
I agree, it would be good to do something about that. You might want to look at how the ldap API handles this kind of thing. If I recall correctly they've got some sort of error object they return which in our case could contain both underlying database error codes, a standardized APR error code, etc.
Right now I am hacking with the autoconf to get the DBD drivers to link as optional shared objects.
Excellent!
-garrett
