apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: apr_dbd API ideas
Date Tue, 22 Feb 2005 02:17:03 GMT
Edward Rudd wrote:
> 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

Mime
View raw message