On Mon, Sep 09, 2002 at 01:19:17PM -0400, Steven N. Hirsch wrote:
> On Mon, 9 Sep 2002, Tim Bunce wrote:
>
> > > Here is a patch againt DBI-1.30 which adds some important
> > > functionality and fixes a minor problem or two.
> >
> > Ohhh, thanks. This is good stuff. I've a few assorted comments and
> > suggested tweaks...
> >
> > > A bug in the ProxyServer table_info() method was fixed. With Perl
> > > 5.8.0 and DBD::DB2 driver v1.26, calling $sth->fetch() in scalar
> > > context is a losing proposition, resulting in the dreaded "Can't use
> > > scalar '1' as an array ref.." exception.
> >
> > Why? A DBD::DB2 driver bug?
>
> I'm not sure. Wouldn't any fetch() method returning an array behave in
> the same manner? For whatever reason, we did not see this problem until
> Perl 5.8.0, so I'm not convinced it's a problem with the DB2 driver.
fetch() is an alias for fetchrow_arrayref, so calling it in a scalar context
should make no difference. Can you look into that? May a trace log would help.
> > > The dbish semantics for table_info also require that a Proxy
> > > table_info call set the statement handle 'Active'. This now works
> > > properly.
> >
> > Thanks. (Though I'm not clear on which bit of the patch addresses that.)
>
> This line in Proxy.pm table_info():
>
> $sth->SUPER::STORE('Active' => 1) if @rows;
Ah. Should probably always be active at first, even if there are no rows.
So no need for the "if".
> > > Synchronous prepare / execute:
> > >
> > > I remain unconvinced that the original "lazy" method (deferring
> > > prepare until the first call to execute) was truly saving any time.
> >
> > For applications not using placeholders and doing lots of non-selects
> > it can significantly reduce the (expensive) round-trips to the proxy server.
> >
> > > Further, although the DBI spec may legalize deferred prepare,
> > > enforcing this on the proxy session when the underlying remote
> > > database has meaningful and distinct prepare behavior violates the
> > > principle of least surprise.
> >
> > Adding support for non-lazy prepare is a valuable addition - but
> > it needs to be made configurable at the dbh level via an attribute.
>
> I'm not sure I agree with you on this. The Proxy should remain as
> transparent as possible to any client applications. By treating it as a
> another attribute in the DBI_AUTOPROXY dsn string, we can avoid the need
> to make any changes to the application. Unless I'm misunderstanding you,
> there would be no way to avoid this if it's only available through the dbh.
Ah, I was forgetting that the DBI_AUTOPROXY env var setting currently
forces a "dbi:Proxy:" prefix and so can't be used to set attributes.
So I'll fix that [...later...] done. Now if the DBI_AUTOPROXY env
var matches /^dbi:/i then the dbi will assume it has the full prefix.
This has two advantages, first we can now set proxy attributes:
DBI_AUTOPROXY=dbi:Proxy(proxy_lazy_prepare=>1):host=...
but also we can use DBI_AUTOPROXY to enable the use of any other
driver that works in a similar way:
DBI_AUTOPROXY=dbi:MyCustomProxy:...
> > > It is often desirable to suppress DBI exceptions and have the program
> > > logic deal with common (or expected) cases. For this to work
> > > transparently, the application must see the actual error information
> > > generated by the remote database. My proposal is to always turn off
> > > 'RaiseError' on the ProxyServer and pass back the database-specific
> > > codes on failure.
> >
> > The code as patched treats execute() returning 0 as an error.
> > It's should check for undef instead.
>
> I had it that way originally, but changed it in the (probably erroneous)
> belief that fetch() returned "OEO" (aka "zero but true") for a successful
> call returning a value of 0. Nonetheless, you are quite correct.
Uh, actually you are also. execute() should always and only return false
if there was an error. (Guess my brain wasn't in gear.) So you can leave it.
> > But I don't see why execute() should be made into a special case.
> > [...]
>
> Cool. I'll play with that a bit.
Great.
> > I'm very glad to see the proxy code getting more use and I'd love
> > to see it improved. Thanks for helping out.
>
> You are quite welcome. Thank YOU for DBI in general! It's made
> development of database applications fun.
:-)
Thanks.
Tim.
