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()
function.
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.
-tom-
p.s. "Enforce ABI versioning using magic" would certainly be a big help preventing user errors with
runtime-registered db drivers.
I don't see how APR could help with "Checking db versions". This seems like it needs to be done
entirely within the driver itself.
-t-
Nick Kew wrote:
On Mon, 12 Mar 2007 14:00:32 +0000
Joe Orton <[EMAIL PROTECTED]> 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).
