[wp-trac] [WordPress Trac] #33501: Starting w/ WP4.2, upgrade scenario may fail for non-MySQL installs

[WordPress Trac]

#33501: Starting w/ WP4.2, upgrade scenario may fail for non-MySQL installs
--------------------------+--------------------
 Reporter:  RSkoon        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:
Component:  Database      |     Version:  4.1.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+--------------------

Comment (by justingreerbbi):

 Replying to [comment:9 RSkoon]:
 > Replying to [comment:8 justingreerbbi]:
 > > Replying to [comment:6 pento]:
 > > > Given that the `is_mysql` flag was created specifically for
 compatibility with non-MySQL db dropins, I'm okay with making some changes
 to how it works in WPDB.
 > > >
 > > > I think the correct fix would be to change `public $is_mysql =
 null;` to `public $is_mysql = false;`, but I haven't tested that. :-)
 > >
 > > If we follow suit with is_mysql instances in WP, then simply using
 > >
 > > {{{
 > > if ( empty( $this->is_mysql ) ) {
 > >     return false;
 > > }
 > > }}}
 > >
 > > would work just right and would also make the checks uniform
 throughout the entire code base. Just for giggles, I am adding a patch.
 >
 > [[BR]]
 > I think you need both parts of the test...
 >
 > Consider the scenario where a DB Drop-in does explicitly set `is_mysql =
 false`...  Then you'll not properly return out of the function because you
 are only testing for empty().
 >
 > In that edge case, you would still want this:
 > {{{
 > if ( false === $this->is_mysql || empty( $this->is_mysql ) ) {
 >       return false;
 > }
 > }}}
 >

 By gosh that is true! 0_o

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