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

[Brandon Black]

On 6/10/07, Nilson Santos Figueiredo Junior <acid06 at gmail.com> wrote:
> The issue seems to happen on DBI.pm, while tracing the execution I
> noticed that the issue arises when the $sth->execute() statement on
> line 880 triggers another calls to _dbh_execute() before returning.
> When it returns (without throwing any exception), the exception
> handling code on line 883 thinks it died because $@ is set - except it
> didn't.
>
> So apparently, $@ is being set somewhere when it shouldn't because
> MySQL issued only a warning but I couldn't really go on any further
> than this. I'll keep trying to get a reproducible test case this week,
> but maybe you can try taking a shot at it just with this info.
>

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.

-- Brandon