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/
