This queue is for tickets about the DBD-Multiplex CPAN distribution.

Report information
The Basics
Id:
11205
Status:
resolved
Worked:
45 minutes
Users:
TKISHEL: 45 minutes
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
Dan [...] DWright.Org
Cc:
AdminCc:

BugTracker
Severity:
Critical
Broken in:
1.95
Fixed in:
(no value)



Subject: DBD::Multiplex::mx_method_all handles fetchrow_array incorrectly.
It would appear that when you call fetchrow_array() on a Multiplex statement handle, that call gets dispatched by AUTOLOAD to mx_method_all. mx_method_all is then calling mx_do_calls to run fetchrow_array(). mx_do_calls is returning an array of an array, for the one row of results. If the row contained the values 'val1', 'val2', and 'val3', then the return value from mx_do_calls would look like this: ( [ [ 'val1', 'val2', 'val3' ] ] , [ ] ) # second empty array is $errors The problem is that this code: for (@$results) { push(@return_results, $_->[0]) if defined $_->[0]; } is extracting only the first value out of each inner array. So in the above example, @return_results ends up containing only ( 'val1' ). In the case of fetchrow_array(), this is the wrong behavior. I haven't taken the time to look and see if there are cases when it is actually the correct behavior. So, here is a patch that fixes the one specific case of fetchrow_array. I'm sure there is probably a more eligant way of fixing it, but this will do the job.

Message body not shown because it is not plain text.

Thanks for the notice and the patch. In 1.96 have updated the module to distinguish been the use of an array in place of a scalar when setting up a Multiplex wantarray context versus a fetchrow_array wantarray context. I will review selectrow_array for similar behavior. -- Tom Kishel


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.