On 4/5/06 9:26, "Garrett, Philip (MAN-Corporate)"
<[EMAIL PROTECTED]> wrote:

>> -----Original Message-----
>> From: Paul DuBois [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, April 05, 2006 2:55 AM
>> To: Garrett, Philip (MAN-Corporate); dbi-users@perl.org
>> Subject: Re: Not exactly a dbi question
>> 
>> On 4/4/06 15:31, "Garrett, Philip (MAN-Corporate)"
>> <[EMAIL PROTECTED]> wrote:
>> 
>>>> -----Original Message-----
>>>> From: Paul DuBois [mailto:[EMAIL PROTECTED]
>>>> Sent: Tuesday, April 04, 2006 4:20 PM
>>>> To: Jonathan Mangin; Garrett, Philip (MAN-Corporate);
>>> dbi-users@perl.org
>>>> Subject: Re: Not exactly a dbi question
>>>> 
>>>> On 4/4/06 15:06, "Jonathan Mangin" <[EMAIL PROTECTED]> wrote:
>>>> 
>>>>> Autocommit is on. Perhaps you're misunderstanding. An update is not
> 
>>>>> supposed to happen if the column to be updated is equal to the data
> 
>>>>> being stuffed into it. I want $row to reflect that but $row is
>>>>> always 1 even when an update did not happen. Is it broke?
>>>>> 
>>>>> --Jon
>>>> 
>>>> No, the default changed:
>>>> 
>>>> 2003-06-22  Rudy Lippan  <[EMAIL PROTECTED]> (2.9002)
>>>>     * moved pod into mysql.pm from mysql.pod
>>>>     * Changed the default behaviour of mysql_found_rows, so now
>>>>       'UPDATE table set field=?' will return the number of rows
>>>>       matched
>>>>       and not the number of rows physically changed. You can get the
>>>>       old
>>>>       behaviour back by adding "mysql_found_rows=0" to the dsn
> passed
>>>>       to connect.
>>> 
>>> Sorry, I've been answering your question while assuming the mysql
>>> driver conformed to the documented DBI interface.
>>> 
>>> Perhaps this is a mysql thing, not a DBD::mysql thing?
>> 
>> Perhaps. What is the non-conformity to the documented DBI interface to
>> which you refer?
> 
> The DBI pod says:
> 
>     For a non-SELECT statement, execute returns the number of rows
>     affected, if known. If no rows were affected, then execute returns
>     "0E0", which Perl will treat as 0 but will regard as true. Note that
>     it is not an error for no rows to be affected by a statement. If the
>     number of rows affected is not known, then execute returns -1.
> 
> The OP said that execute() was returning 1, whether the row was affected
> or
> not.

I don't think there is an error here unless the meaning of "affected"
becomes defined more precisely.  For non-SELECT statements, "rows affected"
can mean either "rows matched" (regardless of whether actually changed) or
"rows changed".  The default for MySQL is the rows-changed value, and that
was also the default for DBD::mysql until the 2.9002 change.  The default
for DBD::mysql now is the rows-matched value.


Does the DBI spec require some particular interpretation of "affected"?
(The JDBC spec requires the rows-matched value.)


Reply via email to