On Oct 28, 2009, at 2:59 AM, Tim Bunce wrote:
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, let's pretend they don't exist here.
Here's a deal: you write some tests for ChildCallbacks in
t/70callbacks.t and I'll implement them.
Deal.
Oh, nice. Does that mean you'll have more time for the DBI?
That's the hope.
W00t.
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.
Out of my league.
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.
If I'm applying a callback to the "fetch" method, I expect it to
execute when I actually call the fetch method on the STH to which I
applied it. Reasonable, no? Is there some reason that wouldn't happen?
If so, I'd call it a bug in the driver, frankly.
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.
I was thinking it would get the same arguments as the precallback,
with an additional one that's a reference to the return value(s).
Best,
David
