Add new footnote to clarify the meaning of "affected rows" in the DB-API.
See DB-SIG mailing list for a discussion: http://mail.python.org/pipermail/db-sig/2012-June/005856.html
This commit is contained in:
parent
3e3a1a3b77
commit
a4ef40c921
16
pep-0249.txt
16
pep-0249.txt
|
@ -287,7 +287,7 @@ Cursor Objects
|
|||
This read-only attribute specifies the number of rows that
|
||||
the last .execute*() produced (for DQL statements like
|
||||
'select') or affected (for DML statements like 'update' or
|
||||
'insert').
|
||||
'insert'). [9]
|
||||
|
||||
The attribute is -1 in case no .execute*() has been
|
||||
performed on the cursor or the rowcount of the last
|
||||
|
@ -1127,6 +1127,20 @@ Footnotes
|
|||
implement the tp_iter slot on the cursor object instead of the
|
||||
.__iter__() method.
|
||||
|
||||
[9] The term "number of affected rows" generally refers to the
|
||||
number of rows deleted, updated or inserted by the last
|
||||
statement run on the database cursor. Most databases will
|
||||
return the total number of rows that were found by the
|
||||
corresponding WHERE clause of the statement. Some databases
|
||||
use a different interpretation for UPDATEs and only return the
|
||||
number of rows that were changed by the UPDATE, even though
|
||||
the WHERE clause of the statement may have found more matching
|
||||
rows. Database module authors should try to implement the more
|
||||
common interpretation of returning the total number of rows
|
||||
found by the WHERE clause, or clearly document a different
|
||||
interpretation of the rowcount attribute.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
|
||||
Many thanks go to Andrew Kuchling who converted the Python
|
||||
|
|
Loading…
Reference in New Issue