Originally Posted by
Cindy2010
We first do a select, for example, we find we need to update 5 rows.
When a update to update them. We assume these 5 rows are updated.
However, during that time period, some other process may change the record, so we may end up with only updated 4 records (for example).
If we don't check this again, we will wrongly return and tell the calling code that 5 rows are updated (which is not true, in this case, only 4 row are updated).
So a good practice in database is always to check exactly how many rows are updated, after a update sql.
While in certain cases checking the number of rows affected is "good practice", it can be irrelevant in many cases too, other than maybe looking for a non-zero value.
Also consider the fact that if you're performing, for example, and update on 5 rows but 2 of them actually already have the value you're updating them to, then mysql_affected_rows will only return "3", which is another completely different but totally valid case vs the race-condition you were referring to above.
So, it's not an exact science to rely on mysql_affected_rows in every situation. It must be used carefully.
Nevertheless, there is no support for mysql_affected_rows in the current query_factory.
However, you can easily call it directly:
Code:
$check_affected = mysql_affected_rows();
Bookmarks