DBD 2.9002 and documentation

DBD 2.9002 changed the behavior of returned value from do(): it now returns the number of *matched*
rows by default, and not the number of actually-changed rows. This is documented in the changelog.

However, the DBI documentation states the value returned is the number of affected rows (not
matched rows), and even still claims (under the "MySQL features") that you can "change this using
a connection-string parameter".

This suggests to me that the documentation is wrong: it acknowledges that both options exist, and
that claims the default is something which it's not.

The question is also what happens in the C (and other) API: is this the default or not? Is the default
*different* between APIs?

In short, is this:
1) A documentation error, and all API's are aligned, or:
2) A DBD-specific error, which should conform to some default but doesn't.

Thanks,
Nitzan



--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules [at] m .gmane.org
Nitzan Shaked [ Mi, 14 September 2005 09:57 ] [ ID #966042 ]

Re: DBD 2.9002 and documentation

On Wed, 14 Sep 2005, nitzan shaked wrote:

> DBD 2.9002 changed the behavior of returned value from do(): it now returns the number of *matched*
> rows by default, and not the number of actually-changed rows. This is documented in the changelog.
>
> However, the DBI documentation states the value returned is the number of affected rows (not
> matched rows), and even still claims (under the "MySQL features") that you can "change this using
> a connection-string parameter".
>
> This suggests to me that the documentation is wrong: it acknowledges that both options exist, and
> that claims the default is something which it's not.
>

The docs are wrong. I probably forgot to update them when I made the change.
Mea culpa, mea culpa....

> The question is also what happens in the C (and other) API: is this the default or not? Is the default
> *different* between APIs?
>
> In short, is this:
> 1) A documentation error, and all API's are aligned, or:
> 2) A DBD-specific error, which should conform to some default but doesn't.
>

Neither :). It is a documentation error, and the documentation should
read that rows() (and do()) returns the number of matched rows by default. The
C API defaults to the number of changed rows, so if you want the C API
behaviour, you have to pass "mysql_found_rows=0" to connect.

-r

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules [at] m .gmane.org
Rudy Lippan [ Mi, 14 September 2005 15:55 ] [ ID #966043 ]

Re: DBD 2.9002 and documentation

At 9:55 -0400 9/14/05, Rudy Lippan wrote:
>On Wed, 14 Sep 2005, nitzan shaked wrote:
>
>>DBD 2.9002 changed the behavior of returned value from do(): it now
>>returns the number of *matched*
>>rows by default, and not the number of actually-changed rows. This
>>is documented in the changelog.
>>
>>However, the DBI documentation states the value returned is the
>>number of affected rows (not
>>matched rows), and even still claims (under the "MySQL features")
>>that you can "change this using
>>a connection-string parameter".
>>
>>This suggests to me that the documentation is wrong: it
>>acknowledges that both options exist, and
>>that claims the default is something which it's not.
>>
>
>The docs are wrong. I probably forgot to update them when I made the change.
>Mea culpa, mea culpa....
>
>>The question is also what happens in the C (and other) API: is this
>>the default or not? Is the default
>>*different* between APIs?
>>
>>In short, is this:
>>1) A documentation error, and all API's are aligned, or:
>>2) A DBD-specific error, which should conform to some default but doesn't.
>>
>
>Neither :). It is a documentation error, and the documentation
>should read that rows() (and do()) returns the number of matched
>rows by default. The
>C API defaults to the number of changed rows, so if you want the C
>API behaviour, you have to pass "mysql_found_rows=0" to connect.

Also, with regard to the "(and other)", there are other APIs that
have a different default than the C API -- MySQL Connector/J (JDBC)
also defaults to rows-matched, because that it required by the JDBC
spec.
--
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules [at] m .gmane.org
Paul DuBois [ Mi, 14 September 2005 18:31 ] [ ID #966044 ]

úùåáä: Re: DBD 2.9002 and documentation

Rudy=2C Paul

Thanks for your answers=2E At least now I know this is the intended beha=
vior and I feel better in relying on this=2E

Best regards=2C
Nitzan

----- ä=E5=E3=F2ä =EE=F7=E5=F8=E9=FA -----
=EE=E0=FA=3A Rudy Lippan =3Crlippan=40remotelinux=2Ecom=3E
=FA=E0=F8=E9=EA=3A =E9=E5=ED =E3=27=2C =F1=F4=E8=EE=E1=F8 14=2C 2005 16=3A=
55
=F0=E5=F9=E0=3A Re=3A DBD 2=2E9002 and documentation

=3E =

=3E =

=3E On Wed=2C 14 Sep 2005=2C nitzan shaked wrote=3A
=3E =

=3E =3E DBD 2=2E9002 changed the behavior of returned value from do()=3A=
it =

=3E now returns the number of *matched*
=3E =3E rows by default=2C and not the number of actually-changed rows=2E=
=

=3E This is documented in the changelog=2E
=3E =3E
=3E =3E However=2C the DBI documentation states the value returned is th=
e =

=3E number of affected rows (not
=3E =3E matched rows)=2C and even still claims (under the =22MySQL =

=3E features=22) that you can =22change this using
=3E =3E a connection-string parameter=22=2E
=3E =3E
=3E =3E This suggests to me that the documentation is wrong=3A it =

=3E acknowledges that both options exist=2C and
=3E =3E that claims the default is something which it=27s not=2E
=3E =3E
=3E =

=3E The docs are wrong=2E I probably forgot to update them when I made =

=3E the change=2E
=3E Mea culpa=2C mea culpa=2E=2E=2E=2E
=3E =

=3E =3E The question is also what happens in the C (and other) API=3A is=
=

=3E this the default or not=3F Is the default
=3E =3E *different* between APIs=3F
=3E =3E
=3E =3E In short=2C is this=3A
=3E =3E 1) A documentation error=2C and all API=27s are aligned=2C or=3A=

=3E =3E 2) A DBD-specific error=2C which should conform to some default =

=3E but doesn=27t=2E
=3E =3E
=3E =

=3E Neither =3A)=2E It is a documentation error=2C and the documentatio=
n =

=3E should =

=3E read that rows() (and do()) returns the number of matched rows by =

=3E default=2E The
=3E C API defaults to the number of changed rows=2C so if you want the C=
=

=3E API =

=3E behaviour=2C you have to pass =22mysql=5Ffound=5Frows=3D0=22 to con=
nect=2E
=3E =

=3E -r
=3E


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules [at] m.gmane.org
Nitzan Shaked [ Do, 15 September 2005 01:08 ] [ ID #967935 ]
Datenbanken » gmane.comp.db.mysql.perl » DBD 2.9002 and documentation

Vorheriges Thema: DBD:mysql make test fails
Nächstes Thema: make fails with intel c++ compiled mysql