apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: apr_dbd: a generic SQL wrapper
Date Thu, 09 Dec 2004 13:39:51 GMT
On Thu, 9 Dec 2004, Garrett Rooney wrote:

> 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.

I'm thinking in terms of the httpd struct and my previous architecture,
where connections are allocated on the server pool, but we don't want
to use that for transient things so I pass it the request pool for that.
The prototypes there are
  foo* open(apr_pool_t* ptmp, server_rec* s)
  foo* acquire(request_rec*)
either of which *may* cause a new connection to be opened if one
isn't available.
Secondly, registering the cleanup is optional: the first pool can be NULL.

> 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?

Because a null pool is explicitly allowed - indeed required if a null
pool was passed to apr_dbd_open.  See the comments in apr_dbd.h.

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

No good reason.

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

To pass to apr_pool_cleanup funcs without a cast :-)

> > 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.


Nick Kew

View raw message