Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

method chaining fails where separate method calls succeed in DBIx::Simple

by Anonymous Monk
on Aug 04, 2011 at 16:36 UTC ( #918585=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

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:
  1. 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?
  2. What is it about method chaining versus several separate method calls that is leading to premature object death?
  3. Is it reasonable to expect method chaining to work the same as breaking down the method chain into a series of separate calls?
  4. 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.

Comment on method chaining fails where separate method calls succeed in DBIx::Simple
Select or Download Code
Re: method chaining fails where separate method calls succeed in DBIx::Simple
by thenaz (Beadle) on Aug 04, 2011 at 18:08 UTC

    I'm guessing that the reason it is important to not increase the reference count, is that the database object keeps references to its active statements. So if the database object references its statements, and the statements reference the database object, you have a circularity, which breaks Perl's reference-counting GC scheme (you'll have a memory leak).

      ...you have a circularity, which breaks Perl's reference-counting GC scheme

      But isn't this what Scalar::Util::weaken() is for — as (somewhat indirectly) hinted at in the OP ?

      (Though I suspect that what Juerd meant with "it's safer to just have a string" is that if you take a copy of a weak ref, the copy will be strong again, which could potentially lead to the problem you mention...)

      PS: I'm not the original poster.

      Somewhat more specifically, you want to know when the statement handle is no longer being used so that it can clean itself up (and perhaps warn that you left it in an unfinished state, probably indicating a bug).

      The described bug that is prevented by removing the quoting sounds exactly like somebody has a bug in their ref count management in their XS code. It sounds like somebody has marked a variable as "mortal" and so the subsequent method call decrements the variable's ref count, destroying it even though an attempt is then made to use it. The destruction doesn't happen if the returned blessed reference is saved into a named variable.

      Have fun finding the ref counting bug in the XS code. It is rarely even close to an easy task. On the other hand, introducing such bugs is extremely easy in XS code and is probably one of the major contributors to the rather frequent problems I see with "weird bugs" that just "go away" when some XS module stops being used (even though the XS module doesn't even seem related to the "weird bug").

      I wish more XS authors learned to only manipulate Perl data structures from Perl code, strictly minimizing their XS code. Or, usually better, just skip the XS code altogether.

      - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://918585]
Front-paged by Eliya
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2014-11-25 00:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (148 votes), past polls