Tests failures with mysql-8.0/8.0.28

[utkarsh2102]

Hey,

Thank you for your work on maintaining this library. However with mysql-8.0/8.0.28 in Ubuntu Jammy, the tests fail with the following error:

Failures:

  1) Mysql2::Statement should prepare DateTime values with microseconds
     Failure/Error: expect(result.first['a'].strftime('%F %T.%5N %z')).to eql(now.strftime('%F %T.%5N %z'))

     NoMethodError:
       undefined method `strftime' for "2022-02-20 13:34:14.808610":String
       Did you mean?  strip
     # ./spec/mysql2/statement_spec.rb:176:in `block (2 levels) in <top (required)>'

  2) Mysql2::Statement should prepare Time values with microseconds
     Failure/Error: expect(result.first['a'].strftime('%F %T.%5N %z')).to eql(now.strftime('%F %T.%5N %z'))

     NoMethodError:
       undefined method `strftime' for "2022-02-20 13:34:14.842138":String
       Did you mean?  strip
     # ./spec/mysql2/statement_spec.rb:168:in `block (2 levels) in <top (required)>'

Happen to know what's causing this?

[basak]

Downstream bug with analysis here: https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1961617

What's causing this is a change in behaviour between 8.0.27 and 8.0.28 (I think 8.0.23 in the bug title is wrong). MySQL is now returning a string (VARCHAR or similar?) instead of DATETIME when called with "SELECT ? AS a" and a parameter of MYSQL_TYPE_DATETIME.

Question for this project: does this change in behaviour represent an issue for users of this package, or just the testsuite? In other words, is it sufficient to just adjust the test to cater for this? Or would this ignore an actual bug?

[utkarsh2102]

Okay, that helps. I think I can make this work (or at least can get a lot closer!), thank you, @basak!

[dbussink]

It looks like this was a breaking change in upstream MySQL which will be fixed in 8.0.29, see also https://bugs.mysql.com/bug.php?id=106352.

I don't think the driver here should try to work around the upstream change then and it would only affect 8.0.28 then.

[sodabrew]

Closing as this was fixed upstream, thank you for linking!