[Dbix-class] DBIx::Class 0.07999_05 (aka 0.08 RC2) released

Brandon Black blblack at gmail.com
Mon Jun 11 15:25:36 GMT 2007


On 6/11/07, Nilson Santos Figueiredo Junior <acid06 at gmail.com> wrote:
> On 6/11/07, Brandon Black <blblack at gmail.com> 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



More information about the Dbix-class mailing list