Bug #30847 for DBI: DBI 1.601 t/85gofer.t dies trying to call "executed_flag

Mon Nov 19 11:51:23 2007 cpan [...] pjedwards.co.uk - Ticket created

Subject:

DBI 1.601 t/85gofer.t dies trying to call "executed_flag_set" on undef value.

Thanks for DBI. I was testing 1.601 on VMS and it's now passing all tests without modification, but I noticed because 85gofer.t has "no_plan" that when t/85gofer.t dies trying to call "executed_flag_set" on undef value this is not being reported as a failure. I'm not sure if it should or not. I also tested 1.601 on Linux, and I observed the same behaviour. Running with: perl -Mblib t/85gofer.t ok 233 ok 234 Testing no transport with pedantic policy dbi:DBM:dbm_type=SDBM_File;lockfile=0 ok 235 - should connect to dbi:DBM:dbm_type=SDBM_File;lockfile=0 ok 236 ok 237 ok 238 ok 239 - should detect prepare failure ok 240 ok 241 ok 242 ok 243 ok 244 ok 245 Can't call method "executed_flag_set" on an undefined value at t/85gofer.t line 160. 1..245 # Looks like your test died just after 245. If you run with prove -b -v t/85gofer.t or "make test" then it's not obvious the test is exiting with an error. I dug a little and found DBD::DBM was calling DBD::File's FETCH and looking for the attribute "go_response", this ends up in these comments: lib/DBD/File.pm sub FETCH ($$) { my ($dbh, $attrib) = @_; if ($attrib eq 'AutoCommit') { return 1; } elsif ($attrib eq (lc $attrib)) { # Driver private attributes are lower cased # Error-check for valid attributes # not implemented yet, see STORE # return $dbh->{$attrib}; } # else pass up to DBI to handle return $dbh->SUPER::FETCH($attrib); } So I guess it's not implemented yet? Cheers, Peter (Stig) Edwards

Mon Nov 19 13:50:44 2007 TIMB [...] cpan.org - Correspondence added

Thanks Peter. The FETCH is fine. It's only the "Error-check for valid attributes" that's not implemented. The question is why is $dbh->{go_response} undef at that point? The preceding $dbh->do(...) executes DBD::Gofer's do method which calls $dbh- Show quoted text

>go_dbh_method(...). And go_dbh_method explicitly sets $dbh->{go_response} :

my ($response, $retransmit_sub) = $transport->transmit_request($request); $response ||= $transport->receive_response($request, $retransmit_sub); $dbh->{go_response} = $response or die "No response object returned by $transport"; Could you look into into that for me? Thanks!

Mon Nov 19 13:50:46 2007 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 19 17:18:57 2007 cpan [...] pjedwards.co.uk - Correspondence added

From:

cpan [...] pjedwards.co.uk

TIMB >> The question is why is $dbh->{go_response} undef at that point? TIMB >> The preceding $dbh->do(...) executes DBD::Gofer's do method Ah, right, I think I'm wasting your time, sorry. It's the: -t STDOUT in: my $perf_count = (@ARGV && $ARGV[0] =~ s/^-c=//) ? shift : (-t STDOUT) ? 100 : 0; when running "make test" or "prove ..." STDOUT is not open to a tty so $perf_count is 0. However, when running "perl -Mblib t/85gofer.t" STDOUT is open to a tty so $perf_count is 100. this line in 85gofer.t is only run when $perf_count is true 97 # to get baseline for comparisons if doing performance testing 98 run_tests('no', {}, 'pedantic') if $perf_count; Because transport is 'no', $dsn gets set to $remote_dsn 127 my $dsn = "dbi:Gofer:$driver_dsn;dsn=$remote_dsn"; 128 $dsn = $remote_dsn if $transport eq 'no'; 129 print " $dsn\n"; This is: dbi:DBM:dbm_type=SDBM_File;lockfile=0 Hence not a DBD::Gofer in sight when using "perl -Mblib t/85gofer.t" My fault. Stig

Tue Nov 20 09:12:31 2007 TIMB [...] cpan.org - Correspondence added

Definitely not wasting my time! I've fixed the bug in t/85gofer.t in r10284. Thanks!

Tue Nov 20 09:12:34 2007 TIMB [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #30847 for DBI: DBI 1.601 t/85gofer.t dies trying to call "executed_flag_set" on undef value.