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: a generic SQL wrapper
Date Thu, 09 Dec 2004 13:23:13 GMT
Nick Kew wrote:
> On Mon, 6 Dec 2004, Nick Kew wrote:
>>Currently I have code for a proposed apr_dbd that compiles and loads
>>cleanly, comprising apr_dbd.[c|h], a MySQL driver apr_dbd_mysql,
> I've now added a test program, and the drivers for MySQL and PostgreSQL
> work for me.  Time to post here for preliminary review.
> I attach the current candidate APR software:
> apr_dbd.h	- specifies the API
> apr_dbd.c	- implements (skeleton) framework
> apr_dbd_mysql.c	- driver for MySQL
> apr_dbd_pgsql.c - driver for PostgreSQL
> apr_dbd_test.c	- test program
> There's a package containing this together with some related stuff
> at http://www.apache.org/~niq/apache-dbd.tar.bz2
> If it is accepted as a startingpoint for an apr-util module, I'll
> donate it to ASF and license it all under ASF terms.
> If not, all rights reserved.

This looks very cool.  I've got a few questions/comments though, just 
from a quick review.

Why does apr_dbd_open take a temp pool?  Can't it just create a scratch 
subpool and destroy it at the end of the function?  I can't recall any 
other public APIs that take multiple pools.

Why does apr_dbd_close specifically check if the pool it's given is 
NULL?  Most other places in APR die in the face of bad input, why is 
this different?

Why do some of the typedefs end in _t and some not?

Why does the close function take a void arg?  Can't we just pass it an 
apr_dbt_t *?

> The Prepared Statement stuff is ugly: do any of the Perl folks know
> how Perl DBI deals with different syntaxes and backends, and is there
> anything we can usefully steal?

That's a good question...  I'll have to think about that.


View raw message