in reply to Re^4: Class::DBI::AbstractSearch and SpeedyCGI
in thread Class::DBI::AbstractSearch and SpeedyCGI

All the debugging code I put in never showed a called with an undef for the ID... But even if it was there, it doesn't seem to bomb: 
@r = MyApp::Sets->search_where(ID => undef); 
print Dumper \@r

__OUTPUT__
$VAR1 = [];

[download]
Which is what it should do - return an empty set when the search returns nothing... For now, I've modified Speedy to exit after a single run - this means that I still run my script from the compiled version, but not persistantly. Seems to work around the problem, but of course, not ideal. Any other ideas what I should be looking at? Thanks for all the suggestions so far!

-- zigdon

Replies are listed 'Best First'.
Re^6: Class::DBI::AbstractSearch and SpeedyCGI
by perrin (Chancellor) on Oct 04, 2005 at 20:50 UTC
    You need to trace it up to the root. You said that $args is not there when the problem occurs, so put in some code in the sub that calls that one and keep going until you see how far up the line the problem is occurring.
[reply]
      Hmmm. I think the I found something odd. I added three debugging lines: 
      C:DBI:AS:search_where: (line 31)
  warn "search_where"; 
  warn Dumper ($phrase, \@bind);

C:DBI:retrieve_from_sql: (line 1067)
  warn "retrieve_from_sql"; 
  warn Dumper $sql, \@vals;

C:DBI:sth_to_objects: (line 1125)
  warn "sth_to_objects"; 
  warn Dumper $args;

      [download]
      At each one, I dumped out all the params being worked on. Here's what happens in the page where the problem is consistant... The page loops over multiple items, and it always breaks on the 3rd item. First iteration: 
      search_where -
$VAR1 = '( ID = ? )';
$VAR2 = [
          '3225-1'
        ];

retrieve_from_sql -
$VAR1 = '( ID = ? )';
$VAR2 = [
          '3225-1'
        ];

sth_to_objects -
$VAR1 = [
          '3225-1'
        ];
Attempt to free unreferenced scalar: SV 0x88020e4

      [download]
      Second iteration: 
      search_where -
$VAR1 = '( ID = ? )';
$VAR2 = [
          '5912-1'
        ];

retrieve_from_sql -
$VAR1 = '( ID = ? )';
$VAR2 = [
          '5912-1'
        ];

sth_to_objects -
$VAR1 = [
          '5912-1'
        ];
Attempt to free unreferenced scalar: SV 0x880e61c

      [download]
      Third iteration (and this one breaks): 
      search_where -
$VAR1 = '( ID = ? )';
$VAR2 = [
          '5913-1'
        ];

retrieve_from_sql -
$VAR1 = '( ID = ? )';
$VAR2 = \'5913-1';

sth_to_objects -
$VAR1 = \'5913-1';

MyApp::Sets can't SELECT id, id, setnumber, setrev, name, theme, year,
+ pcs, figs, picture, msrp, instructions, inventory
FROM   SETS
WHERE  ( ID = ? )
: Not an ARRAY reference

      [download]
      Looking at this, it's obvious that for some reason, the 3rd run does change from an arrayref to a scalarref. But I can't see why, or how this happens? There is _nothing_ touching that value between the 2nd debug line and the 3rd debug line. Makes me think it's some sort of thread-safe issue... Except that this particular CGI is just running plain perl - not SpeedyCGI or anything else. How can I dig deeper?

      -- zigdon

[reply]
[d/l]
[select]
        It looks like an obscure case of list context biting you. Take a look at the warnings about \(@foo) in the perlref man page to see what I mean. Maybe your code is using the return value in a list context in the third spot? I would probably throw in some wantarray() checks to see if that's the difference, and maybe break out the debugger.
[reply]
[d/l]

In Section Seekers of Perl Wisdom