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

[Nilson Santos Figueiredo Junior]

On 6/7/07, Brandon Black <blblack at gmail.com> wrote:
> We have a second release candidate now after the (much appreciated)
> feedback from the first one.  Most of the issues were related to
> module dependency issues in the build/test process rather than real
> code regressions, so it's looking pretty good so far.  Please give
> this one a good testing too.  While you're waiting for CPAN to get a
> copy, you can fetch it directly from:

I've just tried running some code that's working perfectly under
0.07006 and it broke on -current and 0.7999_05.

I've tried fiddling with DBIC source code to figure out the cause of
this problem to no avail. This issue might be MySQL specific. It seems
that DBIC is handling a warning as an error in this specific
circumstance.

The error message I get on my Catalyst app is:

Couldn't render template "undef error -
DBIx::Class::Relationship::ProxyMethods::__ANON__():
DBIx::Class::Relationship::ProxyMethods::__ANON__(): Error executing
'SELECT me.item_id, me.item_type, me.size FROM overview_doc_view_size
me WHERE ( ( ( me.item_id = ? AND me.item_type = ? ) ) )':
DBD::mysql::st execute failed: No data - zero rows fetched, selected,
or processed at
E:\cgi\DBIx-Class-repos\branches\DBIx-Class-current\lib/DBIx/Class/Storage/DBI.pm
line 880."

"overview_doc_view_size" is a view, one of the fields is defined by
calling a function. Apparently, this sort of setup can generate this
warning when the select statement inside that function doesn't return
anything. However, I've been trying for the last two hours or so to
reproduce it outside the application with no success.

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.

-Nilson Santos F. Jr.