Re: Named bind params with DBD::Proxy
Tim,
Are you still maintaining DBD::Proxy? Have you had a request for
supporting named parameters?
STH
On Thu, 2004-10-21 at 16:55, Scott T. Hildreth wrote:
I was going bring this up myself. I had this problem the other day.
To get it working I changed the param names to :p1, :p2, ...etc and
used $sth-bind_param(1, 'foo'). For the return param I had to use the
a :p? as well,
i.e.
my $sth = $dbh-prepare(q{
BEGIN
:p3 = some_pkg(:p1, :p2)
END;
});
$sth-bind_param(1, 'foo');
$sth-bind_param(2, 'bar');
$sth-bind_param_inout(3, \$var, 10);
I was considering trying to change DBD::Proxy to use named parameters.
We use DBD::Proxy quite a bit. I didn't know if someone else is
working on it already, so I guess I am asking now?
STH
On Thu, 2004-10-21 at 16:34, Steve Baldwin wrote:
We make extensive use of named bind params in our apps (our DB is Oracle).
I just tried running a test program over DBD::Proxy and found it barfs on
these. Here is the code in DBD::Proxy that doesn't like them .
sub bind_param ($$$@) {
my $sth = shift; my $param = shift;
$sth-{'proxy_params'}-[$param-1] = [EMAIL PROTECTED];
}
Doing a google search on this turned up some pretty old stuff - e.g.
http://www.grin.net/~mirthles/pile/dbi-tim_bunce_call_on_proxy_module_with_o
racle_bind_param.html
Does anyone know whether a fix to DBD::Proxy is planned?
Thanks,
Steve
Re: Named bind params with DBD::Proxy
On Thu, Oct 21, 2004 at 05:00:56PM -0500, Scott T. Hildreth wrote:
Tim,
Are you still maintaining DBD::Proxy?
Yes, with a loose definition of the word maintaining.
Have you had a request for supporting named parameters?
Tim Howell [CC'd] volunteered but not much has happened.
I could give you commit rights to the ./lib/DBD and ./t
directories if you want to help out.
But note that changes to the proxy must take into account that some
people may not be able to upgrade either the client or the server
at the same time - so backwards compatibility is needed on both sides.
I've been bitten by releases that have broken that in the past.
Also the bind ':p1' using '1' trick you mention below only applies
to DBD::Oracle.
Tim.
STH
On Thu, 2004-10-21 at 16:55, Scott T. Hildreth wrote:
I was going bring this up myself. I had this problem the other day.
To get it working I changed the param names to :p1, :p2, ...etc and
used $sth-bind_param(1, 'foo'). For the return param I had to use the
a :p? as well,
i.e.
my $sth = $dbh-prepare(q{
BEGIN
:p3 = some_pkg(:p1, :p2)
END;
});
$sth-bind_param(1, 'foo');
$sth-bind_param(2, 'bar');
$sth-bind_param_inout(3, \$var, 10);
I was considering trying to change DBD::Proxy to use named parameters.
We use DBD::Proxy quite a bit. I didn't know if someone else is
working on it already, so I guess I am asking now?
STH
On Thu, 2004-10-21 at 16:34, Steve Baldwin wrote:
We make extensive use of named bind params in our apps (our DB is Oracle).
I just tried running a test program over DBD::Proxy and found it barfs on
these. Here is the code in DBD::Proxy that doesn't like them .
sub bind_param ($$$@) {
my $sth = shift; my $param = shift;
$sth-{'proxy_params'}-[$param-1] = [EMAIL PROTECTED];
}
Doing a google search on this turned up some pretty old stuff - e.g.
http://www.grin.net/~mirthles/pile/dbi-tim_bunce_call_on_proxy_module_with_o
racle_bind_param.html
Does anyone know whether a fix to DBD::Proxy is planned?
Thanks,
Steve
Re: Named bind params with DBD::Proxy
On Fri, Oct 22, 2004 at 09:00:23AM -0700, Tim Howell wrote: Just a quick note to let everyone know that I haven't dropped off the face of the planet and am, indeed working on DBD::Proxy. I got slammed by a couple of projects on my return from OSCON and the programming side of my job was pushed to the back burner for some time. That said, I'm now actively working on the code and hope to have release-ready code in the next couple of weeks. Great. Thanks Tim. Here are the items I've currently got on the list: 1. Better support for dead connections. In our setup we have applications running with Apache::DBI on linux that need to connect to a ProxyServer running on Win2K. Currently, if the ProxyServer dies for any reason, and then the application attempts to query it using an already established connection, the application dies. I think better behavior would be for an automatic reconnect to be attempted, and, if that fails, for the application to die. As I'm writing this, though, I wonder if it would be better to have the application itself eval a quick test of the dbh returned from DBI-connect and do the reconnect there if there are problems. I'm certainly open to feedback on this. By default it should simply cause the DBI method to fail via $h-set_err(...). Optionally it could support auto-retry *if* AutoCommit is off. But the docs should warn about silent loss of any locks the app may have had. Tim.
Re: Named bind params with DBD::Proxy
On Fri, 22 Oct 2004, Tim Bunce wrote: On Fri, Oct 22, 2004 at 09:00:23AM -0700, Tim Howell wrote: 1. Better support for dead connections. In our setup we have applications running with Apache::DBI on linux that need to connect to a ProxyServer running on Win2K. Currently, if the ProxyServer dies for any reason, and then the application attempts to query it using an already established connection, the application dies. I think better behavior would be for an automatic reconnect to be attempted, and, if that fails, for the application to die. As I'm writing this, though, I wonder if it would be better to have the application itself eval a quick test of the dbh returned from DBI-connect and do the reconnect there if there are problems. I'm certainly open to feedback on this. By default it should simply cause the DBI method to fail via $h-set_err(...). Optionally it could support auto-retry *if* AutoCommit is off. But the docs should warn about silent loss of any locks the app may have had. I agree that it shouldn't do anything magical, after all it's just a proxy. If you want to play with dead connections, I think that the user should just subclass DBI and do his own games in there (assuming set_err() is properly set so the user knows). I think that my DBIx::HA should properly work in conjunction with DBD::Proxy (if it doesn't I'll fix it so it does), and provides the user with all sorts of reconnect stuff. Henri
