[wp-trac] [WordPress Trac] #43578: Unexpected MYSQL data format

[WordPress Trac]

#43578: Unexpected MYSQL data format
-------------------------------------------------+-------------------------
 Reporter:  loranrendel                          |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Database                             |  Release
 Severity:  normal                               |     Version:  4.9.4
 Keywords:  2nd-opinion has-patch has-unit-      |  Resolution:
  tests dev-feedback                             |     Focuses:
-------------------------------------------------+-------------------------
Changes (by soulseekah):

 * keywords:  needs-patch 2nd-opinion => 2nd-opinion has-patch has-unit-
     tests dev-feedback


Comment:

 Interesting case.

 43578.diff makes sure that only built-in/core tables abide by the
 `field_types` rules. Custom tables will always default formats to `%s`,
 unless the developer specifically fiddled with `$wpdb->field_types` in
 some way.

 How it works, the first time `$wpdb->process_field_formats()` is called
 two internal (static) lists are built - one with the current tables (which
 is almost certainly going to only contain core tables), and one with the
 current field types (which is also almost certainly going to only containt
 core field types).

 `process_field_formats()` now accepts a third ghost parameter (since it's
 protected we cannot just add it as a regular parameter since warnings are
 going to be thrown). A `_doing_it_wrong` message is sent out to all
 subclasses not supplying the third parameter. The third parameter is the
 `$table`.

 When the field formats are processed, we make sure that `$table` is a
 built-in table before letting one of the `field_types` supply the default
 format for a field. We also allow custom field overrides to be added to
 `field_types`, these will be respected, except in cases where the field
 name matches a built-in field.

 {{{
 // without patch
 "INSERT INTO `wp_test` (`id`, `user_id`) VALUES (%s, %d)"

 // with patch regular
 "INSERT INTO `wp_test` (`id`, `user_id`) VALUES (%s, %s)"

 // with patch custom field
 $wpdb->field_types['balance'] = '%d';
 "INSERT INTO `wp_test` (`id`, `user_id`, `balance`) VALUES (%s, %s, %d)"

 // with patch custom field collission
 $wpdb->field_types['user_id'] = '%d'; // not much sense, since it already
 exists
 "INSERT INTO `wp_test` (`id`, `user_id`) VALUES (%s, %s)" // note the %s,
 drawback?
 }}}

 It is probably a bad idea to reformat `$wpdb->field_types`, since it is
 public and can be changed or read by developers. Keeping it as is is
 crucial. One idea to overcome this limitation is make `$field_types` an
 object that implements `ArrayAccess`, and has an `add_field_type( $field,
 $format, $table )` method. This is probably over-engineering, though.

 Thoughts?

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