[wp-trac] [WordPress Trac] #32315: $wpdb->insert fails without error msg

[WordPress Trac]

#32315: $wpdb->insert fails without error msg
------------------------------------------+------------------------------
 Reporter:  dlt101                        |       Owner:
     Type:  defect (bug)                  |      Status:  reopened
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Database                      |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:
------------------------------------------+------------------------------

Comment (by dd32):

 Replying to [comment:19 mnelson4]:
 > Now what about `$wpdb->last_query`: should something be put in there
 when this error occurs? No query is ran, and the SQL statement doesn't
 even get generated. But I suspect most folks will still want to check it
 to see what went wrong with their insert or update query (in addition to
 `$wpdb->last_error`).

 This one is a little more difficult, as in some cases a query hasn't been
 provided.
  - For the case in `wpdb::query()` it makes sense IMHO to set `last_query`
 to the aborted query.
  - For the cases in `wpdb::_insert_replace_helper()`, `wpdb::delete()` and
 `wpdb::update()` it seems like not setting a query would be OK, continuing
 to build the query seems like it'll add significant code for small
 benefit. Could also set it to something non-query-like such as
 `\$wpdb->update( $table )`

 Based on the above, I'm indifferent, If the developer provided a query,
 set as last_query (which is what would happen with a DB based failure
 anyway) if they didn't and they've simply called a helper, maybe not?

 I'll be interested on what @pento's thoughts are here though. He's afk for
 the day though AFAIK.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32315#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform