Having a runnable test case that didn't require spending hours trying to get stuff installed helped clarify the described problem.
The basic problem is that the DBIx::Simple object [returned from dbs()] gets destroyed after the DBIx::Simple::Statement object is created [and returned by query()] but before it can be used.
It wasn't, as I initially misunderstood, that the DBIx::Simple::Statement object is actually being DESTROYed before it can be used.
DBIx::Simple goes to some significant lengths to make all DBIx::Simple::Statement objects suddenly become unusable as soon as their parent DBIx::Simple object is destroyed.
I don't pretend to know why this strange lifecycle interplay is implemented or even whether or not it is a good idea.
But thwarting that part of the module design by inducing circular references such that things just never get destroyed is not what I would call a "bug fix", nor "wise".
Here is an abbreviated summary of the differences between runs of your test cases with one I added with and without the "fix" of not quoting $self (matching lines are prefixed with "=" to aid comparison):
Which shows that the 'fix' does indeed prevent a bunch of stuff from being cleaned up until Perl's "global destruction".
Here is my modified test code. The modifications I made to DBIx::Simple are left as a trivial exercise for the reader:
The test case I added makes it clearer how the lifecycle interplay designed into the module is violated:
warn "Starting CASE 4";
{ # CASE 4 - also fails
my $s = constructor;
my $r;
{
my $dbs = $s->dbs;
$r = $dbs->query($Q);
warn sprintf 'Result of DBIx::Simple-from-Local query:
+ %s',
Dumper($r);
}
my $h = $r->hashes;
warn sprintf 'Hashes? %s', Dumper($h);
ok( $r->{st}->isa($desired_class), $desired_desc );
}
|