On Tue, Oct 27, 2009 at 06:07:46PM -0700, David E. Wheeler wrote:
> On Oct 27, 2009, at 3:24 PM, Tim Bunce wrote:
>
>> The "simplest thing that could possibly work" is probably:
>>
>> $dbh->{Callbacks} = {
>> method_foo => sub { ... },
>> method_bar => sub { ... },
>> ChildCallbacks => {
>> method_foo => sub { ... },
>> method_bar => sub { ... },
>> }
>> }
>>
>> so the code that creates a child handle can just check for
>> ChildCallbacks on the parent handle and set those as the Callbacks for
>> the new handle.
>
> That looks nice. Are STHs the only things that are "children"?
DBHs are children of DRHs (but I try to avoid talking about DRHs).
>>> Yes, I saw that in our
>>> [exchange](http://markmail.org/message/m2lr3n74nluh52jn) in 2005. What
>>> would it take to make this happen?
>>
>> Let's get Callbacks and ChildCallbacks documented first.
>
> Okay. Maybe it'll be done when I wake up in the morning? ;-P
Here's a deal: you write some tests for ChildCallbacks in
t/70callbacks.t and I'll implement them.
>>> 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…
>>
>> [Tangental observation: NYTProf v3 is nearly done... :-]
>
> Oh, nice. Does that mean you'll have more time for the DBI?
That's the hope.
>> ChildCallbacks seems like the way to go. Simple, effective, and easy to
>> implement.
>
> Yeah, looks pretty nice. Would we also be able to pass them to prepare()?
No. Much as I'd like to change prepare() to take method attributes like
connect I'm nervous of making that change. I'd happily support someone
else doing the leg work though.
>>> Well, and tie is pretty hackish IMHO.
>>
>> The implementation (and performance) may not be great, but the concept
>> of tie (values vs containers) is good. Overloading would also work.
>> Either way it should be wrapped up in a nice interface.
>
> Such as?
Dunno. Would need some exploration and thought.
>>>> Note that sth callbacks, for example, give you a relatively clean way to
>>>> set the UTF8 flag on fetched data.
>>
>> It seemed like a good idea at the time but I recant that now.
>> It's workable only for someone who knows what driver and methods will be
>> used to fetch data from a given handle. So it's just about okay for
>> in-house use but I couldn't recommend it as a general solution.
>
> I'm starting to fail to see the point of callbacks aside from connect().
> :-(
I'm probably being over-cautious. Most drivers use fetch() or
fetchrow_arrayref() as the lowest-level calling method used by the other
fetch* ad select* methods. So applying the same callback to both would
work find in most cases.
>> It would need post-call callbacks. How they get called would depend on
>> what works most efficiently and reasonably elegantly. I'd guess that the
>> values being returned would be in @_ (as aliases) and $_ would contain
>> the handle.
>
> Hrm. That'd be inconsistent with the way precallbacks work.
Yeah, well, it was just a guess off the top of my head :)
I'd need to think about it and look at what could would be involved and
what would be effcient.
Tim.
