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.)
