On Mon, 13 Dec 2004, Greg Stein wrote: > 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.
Do you not follow [EMAIL PROTECTED] I moved it there in the light of feedback and it now supports statement preparation and parameter binding. The httpd-specific part is now a much smaller module that just deals with MPM and resource lifetime&management issues. > 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. Sounds like you're someone this discussion could really use on [EMAIL PROTECTED]:-) > 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 http://marc.theaimsgroup.com/?l=apr-dev&m=110259565527659&w=2 http://marc.theaimsgroup.com/?l=apr-dev&m=110279584404570&w=2 (the latter is the most up-to-date) You'll notice the code in apr_dbd.c is very minimal and comprises mostly, handling of driver loading/init (APR_HAS_DSO and threads) while apr_dbd.h and the drivers are bigger. > helped a ton. We also said, "do the fancy stuff at a higher layer; we > are simply trying to provide some basic interop." Yep. > Oh, and the notion of swap one provider for another? Pipe dream. Well, I've done this to a limited extent with real apps. Site Valet uses a C++ SQL base class + drivers that instantiate it. That includes functions to generate statements where the SQL syntaxes differ - e.g. MySQL's "INSERT IGNORE" vs INSERT triggering a stored func if the operation would violate a uniqueness constraint. I'm not proposing that for APR - just the basic API for apps to build on. > 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. I'm aware of that: when I had to convert some stuff originally implemented with PostgreSQL to run on Windows, the conversion to MSSQL/ODBC was more work than the original, despite having used Perl's DBI. But that's a learning curve: when you've been there once, you have a better idea what to expect. I feel sure we can do this with common Apache modules including Authentication and Logging, and that a high proportion of LAMP applications would fit at least the lightness criteria. -- Nick Kew
