Opened 14 years ago
Closed 14 years ago
#19467 closed defect (bug) (fixed)
wpdb does not always set rows_affected or insert_id properties when needed
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.5 | Priority: | normal |
| Severity: | minor | Version: | 3.3 |
| Component: | Database | Keywords: | has-patch commit |
| Focuses: | Cc: |
Description
If SQL keywords like INSERT or UPDATE are not followed by a space, the rows_affected and insert_id properties of the wpdb class are not updated. Those keywords might be followed by a newline or a tab character. A simple regex tweak fixes this issue.
<?php // Note the newline after "UPDATE" $wpdb->query(' UPDATE test_table SET foo = "bar" WHERE id = 5 '); // Should not be int(0) in this case var_dump($wpdb->rows_affected);
Attachments (1)
Change History (10)
#3
@
14 years ago
- Milestone changed from Future Release to 3.5
- Severity changed from trivial to minor
Wouldn't it be even better if we allowed multiple spaces, like \s+ ?
#6
@
14 years ago
- Cc Bellfalasch added
I'm not that all familiar with WP, but I am with MySQL. So sorry if I'm all off here =/
An UPDATE which has an valid target with it's WHERE-statement, but doesn't change any data in a table will return rows_affected = 0. An error would produce rows_affected = -1.
If we have the table test with columns id and awesome set to 1 and 'Hi!' respectivly.
First we do this:
UPDATE test SET awesome = 'Bye!' WHERE id = 1
rows_affected = 1
Right after that we run the same SQL and get 0 affected rows since no changes was made in the db.
UPDATE test SET awesome = 'Bye!' WHERE id = 1
rows_affected = 0
I am still able to reproduce this issue in SVN trunk. By that, I mean wpdb->query() incorrectly identifies perfectly valid SQL, resulting in missing rows_affected and insert_id values for SQL statements when they contain white space other than a space after the first query keyword.
I have tested both with and without this patch using one of the existing SQL queries in WP (the attachment post_parent UPDATE) by adding a newline immediately after "UPDATE". This patch has a 4 lines offset, but still applies cleanly, and it does address the issue correctly, and fixes this.