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

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;
[download]

then everything works fine. But, but when you attempt to chain together the method calls:

 my $s = constructor();
 my $r = $s->dbs->query($Q);
[download]

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;
[download]

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.
[download]

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

Replies are listed 'Best First'.
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).	[reply]
Re^2: method chaining fails where separate method calls succeed in DBIx::Simple (XS mortals) by tye (Sage) on Aug 04, 2011 at 18:37 UTC
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	[reply]
Re^3: method chaining fails where separate method calls succeed in DBIx::Simple (XS mortals) by metaperl (Curate) on Aug 10, 2011 at 20:13 UTC
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. There is no XS code involved it makes no sense to have the quoting in the first place. When was the last time you added a component of an object by double-quoting instead of simply putting it there? It's unorthodox. It doesnt make sense. And it causes a bug. The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development. -- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"	[reply]
Re^4: method chaining fails where separate method calls succeed in DBIx::Simple (XS, tests) by tye (Sage) on Aug 10, 2011 at 21:08 UTC
Re^5: method chaining fails where separate method calls succeed in DBIx::Simple (XS, tests) by metaperl (Curate) on Aug 16, 2011 at 16:17 UTC
Some notes below your chosen depth have not been shown here
Re^2: method chaining fails where separate method calls succeed in DBIx::Simple by Eliya (Vicar) on Aug 04, 2011 at 18:28 UTC
...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.	[reply]