On Sat, 27 Nov 2004, Paul Querna wrote: > Nick Kew wrote: > > I have recently developed a first-draft namespace module mod_sql for > > incorporating SQL into HTML/XML pages with mod_publisher or mod_xmlns. > > > > In doing so, I revisited the existing database connection pooling modules, > > and reclassified them as drivers for mod_sql. I also added support for > > LAMP-style single persistent connections for use in non-threaded MPMs, > > using #if APR_HAS_THREADS. > > > > That basically means each database module is an ap_provider for "dbd", > > and implements a common API. > > +1 in concept from me.
:-) > One thing I think needs to be kept in mind is a > separation from Apache-ism so it could be used by Python/PHP/Perl > without requiring Apache. Hmmm, not sure about that. My purpose is a dbi layer specifically for applications running in Apache, working transparently and efficiently across the different MPMs. Outside of an Apache context, we'd be in direct competition with mature, well-established code such as Perl DBI/DBD, and I don't see that we'd be offering the Perl folks anything they don't already have. > > I'd like the DBD API to be generic, and to work for other modules that > > use an SQL backend, ranging from specific modules such as SQL-based > > authentication and logging to general frameworks such as Perl, Python > > and PHP. I don't know to what extent that's going to prove feasible, > > but perhaps my current draft can serve as a startingpoint. What I'd > > really like at this stage is feedback from other developers connecting > > Apache to an SQL backend. > > One thing I believe that is missing from the current API is a method to > store a result set into a var, and then iterate that whenever you want. > (Plus seeking within a result set). Hmmm, yes, that's a straightforward extension to the current implementation. > > Description and source code at > > http://apache.webthing.com/database/ > > An API to use as a starting point might be libdbi. Its public interface > is at http://libdbi.sourceforge.net/docs/programmers-guide/ Looking at that page, there's quite a lot in there that we don't particularly want to expose to Apache modules: - Init/shutdown is the business of drivers not apps. - Driver infrastructure: well, maybe, but within the ap_provider framework, unless you can suggest a better way. - Connection Infrastructure: IMO we want an abbreviated version. The options belong in httpd.conf as config directives for drivers (again, unless you have a better suggestion). - SQL and Database Infrastructure: Yes, I guess we can implement that. In addition, I want to preserve fast options that don't support seek-like things and only process rows in order. - Retrieving field data: Looks useful but boring. Can't see myself giving it high priority, but I agree it should be firmly on the wishlist for round tuits. > They also have a set of documentation on the design of the Database > Driver's API at http://libdbi.sourceforge.net/docs/driver-guide/ Indeed, we're quite close to implementing all that's relevant from that (the main omission seems to be random-access to result sets - which I agree we want to add). > I really like using libdbi, and I have used it for several apache > modules, but its memory management is a painful hack where you are > required to free() and malloc() things yourself. I would love a libdbi > like interface that fully embraced pools. Anyone else? > > If we get to a working code-base, I would like to investigate adding it > to APR-Util. Your project may be more ambitious than mine:-) There are reasons for tying it to httpd: the server and request pools and contexts give us the right architecture for applications. An APR base would need an additional module layer on top, and an alternative to my use of ap_provider. Does it gain enough to be worth the extra effort? -- Nick Kew
