Architecturally, it's a Perl DBD layer which marshals requests and sends them to a Java server which then uses JDBC to talk to the underlying database. Since I don't know which database is being used, I can't provide database-specific methods via $h->func(jdbc_XXX). In order to enable users to call JDBC methods which don't have an exact DBI equivalent, and to call JDBC driver-specific methods which they know about, I've been using a func/AUTOLOAD combination on the Perl side with reflection on the Java side. A call in Perl looks something like this:
$dbh->func("jdbc_getTransactionIsolation");Since DBI 1.39, this doesn't work since jdbc_getTransactionIsolation isn't a declared method.
My current fix is to replace the AUTOLOAD function with a jdbc_func method which does essentially the same thing and to register jdbc_func using install_method. This turns the above into
$dbh->jdbc_func("jdbc_getTransactionIsolation");(allowing for simple search/replace) or
$dbh->jdbc_func("getTransactionIsolation");I've been pretty out of touch with DBI and Perl in general for the last couple of years, so I was wondering if this seems like a reasonable fix or if there's a better way to handle this. (I've been testing this with a locally modified DBI.pm, as recommended in DBM.pm, but obviously it wouldn't go to CPAN until/unless the jdbc_ prefix is added to a future DBI release.)
I considered having some sort of JDBC function list which could be installed using install_method and then (if I'm understanding the description in the DBI CHANGES right) invoked using AUTOLOAD as before. This would still leave open the problem of JDBC driver-specific methods. You could probably have a JDBC driver-specific setup file of some kind, but writing such a file would be up to people who used the particular databases. A coworker also suggested using reflection on the Java server side to do some sort of introspection on the driver(s) available, but I'm not certain how effective or efficient that would be.
Thanks, Gennis
