On Oct 26, 2009, at 1:59 PM, Tim Bunce wrote:

> > It output nothing. When I uncommented that second-to-last line, it  
> > output
> > "Set in STH". So it seems that a callback added to the dbh for a  
> > statement
> > method name does not end up getting passed on to the statement  
> > handle. So I
> > guess the Callbacks attribute is not passed on to statement handles  
> > created
> > for the database handle?
> 
>  Yeap.
> 
> > Seems a shame…
> 
>  I recall thinking about it but opting not to. I can't recall why  
>  though.
>  Possibly just to err on the side of caution.
> 
>  I'm open to persuasion.

I understand the caution, but it does seem inconsistent to me. I'd  
really like to be able to set STH callbacks once in a DBH and be done  
with it, just as a I can any other DBH attributes that also apply to  
STHs.

> > One other thing: It's nice that the callbacks execute before the  
> > method
> > call, so that you can disable it by undefing $_. But it'd be  
> > equally handle
> > to have callbacks after the method call.
> 
>  Yes, I'd always planned for that but never had a need to implement  
>  it myself.
>  I'd figured the callback code ref could, optionally, be an array ref  
>  and
>  if so, the second element would be the callback to call on method  
>  return.

Yes, I saw that in our [exchange](http://markmail.org/message/m2lr3n74nluh52jn 
) in 2005. What would it take to make this happen?

>  Note that a post-prepare() callback could be used to implement
>  inheritance of Callbacks.
> 
>  (If the method attributes of prepare($sql, \%attr) were applied to the
>  newly created sth, in the same way as connect(), then a pre-prepare
>  callback could be used to pass down the $dbh->{Callbacks} to the  
>  $sth.)

Oh, that kind of callback. I'd love to see attributes to prepare  
passed on to the sth. It makes perfect sense to me. I note that you  
thought in 2005 that it wouldn't happen before DBI2, but since that's  
probably another 5 years away at this rate…

> > For example, I'd love to be able
> > to create a callback on a statement handle to convert a timestamp  
> > column to
> > a DateTime object:
> >
> >    $sth->{PostCallbacks}{fetch} = sub {
> >        my ($sth, $row) = @_;
> >        $row->[3] = DateTime::Format::Pg->parse_datetime($row->[3]);
> >    };
> 
>  That particular example is potentially risky - or at least unportable.
>  What if the driver doesn't implement a higher-level method (like
>  fetchrow_hashref or fetchall_* etc) in terms of fetch?

Is that not a problem for any callback on any driver-implemented method?

>  I've always felt the best way to do that kind of thing would be to  
>  tie()
>  the individual elements of the row buffer array - but I've never  
>  needed
>  to do it myself so never explored it.

Well, and tie is pretty hackish IMHO. But let me cite another example.  
In our prior discussions, you [wrote](http://markmail.org/message/dgnpmnzkk4g532lc 
):

>  Note that sth callbacks, for example, give you a relatively clean  
>  way to set the UTF8 flag on fetched data.

Given that callbacks execute before data is fetched, how, exactly,  
could this be done with the current implementation? I would exepct  
something like this (using post-callbacks):

    $sth-> {PostCallbacks}{fetch} = sub {
        my ($sth, $row) = @_;
        Encode::_utf8_on $_ for @$row;
        return;
    };

But that obviously won't work.

>  Another issue to keep in mind is that there's only one callback per  
>  method.
>  In other words there's no way for multiple callbacks for a single
>  method to coexist on a handle. That limits the usefulness of Callbacks
>  in general.

Maybe. I don't think it's like JavaScript where you have any number of  
libraries all adding their callbacks to global DOM elements. We have  
lexical handles that can be modified only in scope. I don't think  
there's much need to worry about supporting multiple callbacks until  
someone needs them. And even then I'd suggest:

     if (my $cb = $sth-> {Callbacks}{fetch}) {
         $sth-> {Callbacks}{fetch} = sub {
             $cb-> (@_);
              ... #other stuff ...
         }
     } else {
         $sth-> {Callbacks}{fetch} = sub {
              ... #other stuff ...
         }
     }

I dont think additional infrastructure is needed until the cowpaths  
demand it.

>  Ideally I'd like to see an abstract interface for managing callbacks,
>  rather than the current "stuff it in a hash". That way future support
>  for post-method callbacks and multi-callbacks per method and handle
>  could be added without exposing (and locking us into) particular
>  implementation details.

Do you have something in mind? What would it look like?

Best,

David