On 6/11/07, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote:
On 6/11/07, Brandon Black <[EMAIL PROTECTED]> wrote:
> Are you sure $@ is being set? If $sth->execute() is returning a false
> value that would trip up the current code as well (as it checks !$rv).
> DBI says false return values are an error for $sth->execute (zero
> rows is "0E0", which is zero but true), but perhaps MySQL + DBD::mysql
> return an actual zero in your case? Come to think of it, since we now
> enforce RaiseError (and doc that coderef connect users should be
> setting it, it's arguable we shouldn't be checking the retval for
> errors at all. You might look at what $rv is near that line 883,
> and/or try removing the !$rv check.
$@ is set and $rv is false but no real error occurred. The issue seems
to happen because when the failing $sth->execute() is called, another
two calls to _dbh_execute() are issued before the first
$sth->execute() returns.
I couldn't really understand why it happens that way, but those
"nested" calls seemed to be somewhat related to
DBIx::Class::Storage::DBI::Cursor since it was being passed as one of
the parameters.
The basic flow of a normal (potentially multi-row) select is (assuming
no errors along the way):
S::DBI->select returns a new S::DBI::Cursor object
S::DBI::Cursor->next detects that it doesn't yet have any $sth, so it
calls S::DBI::->_select to get one
S::DBI->_select does some perl pre-processing, then calls
S::DBI->_execute() to generate/execute the $sth.
S::DBI::Cursor->next then uses the $sth to do fetchrow, and will keep
using it for subsequent row fetches.
Of course, at any point an exception can occur. Assuming the $dbh is
still connected after the exception (wasn't a "no connection"
exception, basically), the error should be rethrown all the way out to
your application code. If it was a disconnect, the $dbh will be
regenerated, the $sth will be regenerated from the new $dbh, and
things pick up where they left off (except that currently it will
reset the iterator - in the future we could try to pick up the
iterator where we left off too, by cycling a few fetchrows and
ignoring the retvals, but I doubt this is affecting you).
-- Brandon
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
