Hi,

I've uploaded prereleases of the upcoming libdbi and libdbi-drivers
releases:

http://libdbi.sourceforge.net/downloads/libdbi-1.0-pre1.tar.gz
http://libdbi.sourceforge.net/downloads/libdbi-drivers-1.0-pre1.tar.gz

These prereleases serve the purpose of checking two major changes:


1) The "_r" or "recallable" interface

As discussed previously, libdbi so far had problems to support
projects which dlopen() modules which in turn are linked against
libdbi. As the modules are usually designed to operate independently,
both dbi_initialize() and dbi_shutdown() may be invoked more than once
within the same process and wreak havoc on modules that expect their
connections to be around as long as they run. The functions
dbi_initialize(), dbi_shutdown(), dbi_set_verbosity(),
dbi_driver_list(), and dbi_driver_open() now have equivalent
implementations carrying the name suffix "_r". dbi_initialize_r()
fills in a handle which the other functions use to access a particular
libdbi "instance". A new function dbi_driver_get_instance() allows a
connection to determine the instance. These changes were requested and
largely implemented by Rainer Gerhards.

2) library versioning

libdbi so far used arbitrary release numbers. libdbi-drivers release
numbers were only half-arbitrary in that they were chosen to make it
easy to guess which libdbi version they'd run with. Moreover, although
libdbi is set up to use the libtool library versioning scheme, the
version information has never been updated since the first
release. This didn't haunt us so far, as the library is still
backwards-compatible. However, it is just a matter of time until
something breaks.

Therefore I went ahead and set up configure.in to assemble the libdbi
version string from the (now updated) libtool library version
numbers. This eliminates one point of failure (no need to change *two*
numbers) and results in reasonable version numbers. The next official
release will be "1.0". If we add features that do not alter the
interface, there will be "1.1", "1.2"... releases. If we alter the
interface, a "2.0" release will follow. libdbi-drivers release numbers
will match these, so "1.x" will again be compatible with any "1.y"
libdbi release.

Also, libtool takes care of tagging the shared objects appropriately
(at least on unixish systems). After installing the prerelease, you'll
find a libdbi.so.1 right next to your existing libdbi.so.0. This
allows the loader to detect applications that were not linked against
a compatible version of the library if we'll ever have to introduce
changes which are not backwards-compatible.

While the new interface and the new versioning scheme made it into the
programmers manual, I didn't get round to add an UPGRADING file
yet. In brief, upgrading isn't that hard at all. Although the older
interface functions are labelled as "deprecated", they are still
around. Therefore your applications should link against 1.0 with no
changes whatsoever. To make use of the new interface, you'll have to
change all occurrences of the old interface functions and replace them
with calls to the new equivalents. It is mandatory *not* to mix old
and new interface function calls! This is almost guaranteed to crash
your app. If you start to migrate, stop no sooner as all "deprecated"
messages in your "make" output are gone. If you want your application
to support both 0.8.3 and 1.0 installations (packaged OSes are
sometimes slow to pick up new versions), you can use wrapper functions
in your program. See tests/test_dbi.c in libdbi-drivers for an example
how this might look like.

Now if you made it until here, please allow me to ask you to test the
new releases on as many OSes as possible. Although the "1.0" label was
chosen for different reasons (see above), unsuspecting users may infer
some sort of stability or maturity. I'd hate to disappoint their
prejudices, so please flood this list with feedback!

regards,
Markus


-- 
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users

Reply via email to