httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Towards a generic database connection API
Date Mon, 13 Dec 2004 08:54:39 GMT
On Fri, Dec 03, 2004 at 12:33:59PM +0000, Nick Kew wrote:
> 
> I've updated the proposed DBD API, and written a better description
> of it at <URL:http://www.apache.org/~niq/dbd.html>.  This defines
> only the API, decoupled from my software implementing it.
>...
> Bearing this in mind, I'd like to
> invite comments again.
> 
> Summary: database applications get the following for free:
>   * Multi-database support
>   * Optimised access to all MPMs
> 
> Should we seek to standardise this?

Feel free, but I'm -1 on it being part of httpd. The API doesn't
support most of the things needed for high-performance database
access. There is no statement preparation, no input/output parameter
binding, no array access, etc. It also appears to be bound to
httpd-isms (e.g. acquire takes a request_rec -- should be an arbitrary
pool). Cursors need to be supported, and it would be great to have
non-string values within the API.

These things don't have to make the API complicated -- it is possible
to have the API scale up with complexity. But it should be possible to
do these things. When Michael Lorton and I designed the Python DBAPI
back in '96, we took a lot of time to ensure that the simple things
were still simple, but it was possible to do serious full-on high-perf
work. Our Python-based data loader was just as fast as Oracle's loader
because we were able to use array-inserts via Python.

I also believe the right level for an API like this would be in APR.
Whether APR itself, or APRUTIL... not sure. I'd think the latter. The
API itself wouldn't have a lot of code; it's going to all be in the
providers. I would also advise an API that is *very* easy for
providers to implement, or you won't get any of them built. That was a
design goal for the Python DBAPI -- make it easy for providers. It
helped a ton. We also said, "do the fancy stuff at a higher layer; we
are simply trying to provide some basic interop."

Oh, and the notion of swap one provider for another? Pipe dream. Apps
will always get coded for one back-end or another. If they are
independent, then they're using the database in very light ways.
That's alright, but it is also very rare. Most apps are very tied to a
database, even if they use a "common API".

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message