Re: Time to Document Callbacks

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