On Mon, Feb 21, 2005 at 04:10:29PM -0800, David Wheeler wrote:
On Feb 21, 2005, at 2:17 PM, Tim Bunce wrote:
Which is also pretty easily done, eh? Something like this?
Yes, though I wouldn't bother validating the contents of the hash.
Just checking you're getting a hash ref is enough I
On Feb 22, 2005, at 1:54 AM, Tim Bunce wrote:
True. The 'if ref' was a little over the top though. If the user
messes with the contents of $h-{Callbacks} then they get what
they've asked for.
Note that the STORE code for Callbacks only gets fired
in a few situations. Specifically, doing
On Feb 21, 2005, at 2:17 PM, Tim Bunce wrote:
Which is also pretty easily done, eh? Something like this?
Yes, though I wouldn't bother validating the contents of the hash.
Just checking you're getting a hash ref is enough I think.
Well, I figured it was faster to do it up-front (during the
On Feb 14, 2005, at 3:14 AM, Tim Bunce wrote:
In relation to connect_cached it boiled down to just the difference
between:
if ($dbh and my $oc = $dbh-{OnConnect}) {
$oc-($dbh, $dsn, $user, $pass, $attr) if ref $oc eq 'CODE';
}
and:
if (my $cb = $dbh-{Callbacks}) {
my $oc =
I'd meant to sent this to the list. Sorry.
On 02/12/2005 07:35 PM, David Wheeler said:
On Feb 12, 2005, at 10:11 AM, Tim Bunce wrote:
That's starting to get might complex, isn't it?
Uh, mite. :-)
Or mighty, perhaps.
Quite.
So, I'm looking at your new_child() stuff, instead. I'm
On Feb 13, 2005, at 2:51 PM, Tim Bunce wrote:
Maybe the answer it to not allow changing attributes on a cached
handle.
That's already the rule and would not change.
Er, that's news to me.
Uh, sorry, I was thinking of the resetting of AutoCommit.
Different applications use handle caching for
