I created a
Moose object which has a method which produces a
DBIx::Simple instance. When this method is called and the
results placed in a scalar:
my $s = constructor();
my $dbs = $s->dbs;
my $r = $dbs->query($Q);
my $h = $r->hashes;
then everything works fine. But, but when you attempt to chain
together the method calls:
my $s = constructor();
my $r = $s->dbs->query($Q);
the result is not the same - you get a dead object.
The reason this happens is that on line
165 of Simple.pm there is an attempt to reduce the reference
count by double-quoting the database handle related to the
statement handle:
# $self is quoted on purpose, to pass along the stringified version,
# and avoid increasing reference count.
$st = bless {
db => "$self",
sth => $sth,
query => $query
}, 'DBIx::Simple::Statement';
$statements{$self}{$st} = $st;
A fix that works for me is to simply remove the double quotes. Then
all 3 test cases in the test program below work.
So I guess my questions are:
- The simple fix for me is to pass the actual database object
instead of the stringified version. is there any practical case where passing the actual database object
would lead to problems?
- What is it about method chaining versus several separate method
calls that is leading to premature
object death?
- Is it reasonable to expect method chaining to work the same as
breaking down the method chain into a series of separate calls?
- If there are cases where having the database object as part of the
statement object poses problems, then how can we support method
chaining and also avoid the problems caused by it?
personally, I don't understand why line
165 of Simple.pm looks the way it does. I asked Juerd about
it and here is what he said:
> Also, is there a reason you didnt use Scalar::Util::Weaken instead o
+f
> quoting an object like that?
I'm not entirely sure what the reason was in this specific case, but i
+n
the general case I think it's safer to just have a string, than to hav
+e
something that when copied does increase the refcount, and could still
be destroyed when you didn't expect it yet. If all you need is somethi
+ng
to recognise the object when you see it, then keeping the entire objec
+t
around is just unnecessary bloat; bloat that could cause many hours of
debugging.
And that makes no sense to me:
- Increasing the refcount is no big deal. It just means the
statement handle is not extinguished until the database handle is
- There is no bloat in adding the reference because it is not
cloned. It's the same reference, just referred to in one more
place.