On 2/12/07, Markus Hoenicka <[EMAIL PROTECTED]> wrote: > Mike Rylander <[EMAIL PROTECTED]> was heard to say: > > > Continuing this long-dormant thread, I want to thank the libdbi core > > team for the help and support in getting basic ISO timezone support > > into the code base. It has helped the Evergreen[1] project immensely, > > as we wouldn't have a fast and stable database connector without it. > > > > It is nice to see such a high-profile project use libdbi successfully! > > > Is it time for 0.8.2? > > > > libdbi has a history of being developed in batch mode. Development usually is > dormant as long as no one complains about bugs or missing features. Maybe it > is
Entirely understandable, especially given that current stability of the code. > time again for a wake-up call to the hibernating developers to collect all > issues which should be addressed in an upcoming new release. From my POV, the > following things come to mind (they have been requested previously, but I > couldn't find the mails right away as I'm away from my development box): > > - change the release version numbers to the library interface numbers. The > issue > has been discussed before > (http://sourceforge.net/tracker/index.php?func=detail&aid=1578577&group_id=65979&atid=512948). > This change will allow better version checks by the runtime linker and thus > will > avoid frustrations when using applications built against an incompatible > libdbi > version. > hmmm... The libtool interface version number is about compatibility, where as the release number is about human-understandable "freshness". These are orthogonal concepts, though the former does deserve attention. It seems to me that the LIB_CURRENT and LIB_AGE should just both be 0, since there is no previously versioned interface. Then LIB_CURRENT just gets bumped when new functions are added, and LIB_AGE gets bumped as old functions are changed, deprecated or removed. Trying to make the version number match the interface number seem both counter productive (a new interface version for each release?) and against libtool best practices, no? ... I may be misunderstanding the proposal, though. > - add a "late binding" interface to libdbi. Currently you have either to know > in > advance which type a particular query is going to return, or you have to add > type checks after each query in order to find out. A "late binding" interface > would allow to request e.g. a string or an integer from any type of field, > with > libdbi performing all required conversions. > That actually seems fairly trivial for all types except DBI_TYPE_BINARY -- that might require base64 encoding or the like. I'll look into doing this. > - the drivers should be overhauled too where necessary. I've fiddled with some > experimental code to improve concurrent accesses with sqlite3. Also, we should > check at least the MySQL and PostgreSQL drivers with the latest versions of > these database engines to work out any compatibility issues. > I've been using the Postgres driver against an 8.2 database in testing, and that seems to work just fine. On a related note, we should also consider adding the "link libdbi into drivers" patch that's been floating around into CVS. Our project requires that we do this, as it uses the Parent => dl_open(app-logic) => dl_open(libdbi) => dl_open(libdbi-driver) pattern. When libdbi goes to load the driver it can't due to missing symbols that the driver requires in the loading binary. Linking libdbi into the drivers fixes this, it's a one line change in the Makefile, and it does not break the more traditional setup. In fact, this would help with the above mentioned libdbi <-> driver interface checks. Note that any apache module that attempts to use libdbi will also suffer from this. > The above issues are just suggestions. If anything else seems worth to be > included in the next release, feel free to add your favourites. > Having said all everything above, I'd personally prefer to see a new version out right now with the current code. It is tested and stable, and does exactly what I need (other than the driver-libdbi linking issue, but that's separate). There seems to have been a descent amount of code added since 0.8.1 was released, and now that this codebase is in use in a large production project (it's been tested stable, etc) my immediate concern is stamping the code as "good" and being able to point others at a tarball to say "that is tested and works." As it stands, I get funny looks (or worse, no second look at all) when I say, "Grab libdbi from CVS. Yes, it's stable and safe, it's just not wrapped up in a download yet." So ... I'm sure you can understand my frustration ... Anyway, thanks again for this awesome package. It's been a huge help, and I'll continue to do what I can as time permits to help improve it. -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
