apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: [PATCH] DBD drivers as DSOs
Date Mon, 12 Mar 2007 19:25:30 GMT
I appreciate that this idea didn't just die as "not supported". Thanks!

Another way to accomplish runtime registration of db drivers would be a public apr_dbd_set_driver()


Using this function the app - or even the driver itself - could register at runtime.

FYI, I entered enhancement request #41807 for this approach;
   but frankly, any method of runtime driver registration would be just fine.


p.s. "Enforce ABI versioning using magic" would certainly be a big help preventing user errors
runtime-registered db drivers.

I don't see how APR could help with "Checking db versions". This seems like it needs to be
entirely within the driver itself.


Nick Kew wrote:
> On Mon, 12 Mar 2007 14:00:32 +0000
> Joe Orton <jorton@redhat.com> wrote:
>>> The intention was that apr_dbd_internal.h should be used by DBD
>>> drivers but opaque to applications.
>>> Is there a better way to express that, that'll properly support
>>> out-of-tree drivers?
>> I'd say:
>> 1) Move the apr_dbd_internal.h header out of the private/ subdirectory
>> and give call it something other than "_internal.h"
> I guess that means relegating "don't use this in anything other
> than a driver" to a comment and the documentation?
>> 2) Commit to API/ABI stability in the driver interface; stuff like
>> r508700 would subsequently require a major version bump
> That should be less of an issue now than when it was very new.
>> 3) Enforce ABI versioning at DSO load time e.g. using magic at the
>> beginning of the driver structure
> +1.  I wonder if we could extend that to database versions too,
> where there are minor but important API version differences,
> and #ifdefs (as between MySQL 4.1 and 5.0).

View raw message