Tickets :: Comment on [#14984] Horde Database Libraries tests fail against fail on MySQL 8.0.19 and later

* Your Email Address
* Spam protection	Enter the letters below: . ..__.. ..___. . \ /\| \|\| \|[__ \| \| \/ \|__\\|__\|\| \|__\|
Comment	> The failures are: > > There were 2 failures: > > 1) Horde_Db_Adapter_MysqliTest::testColumns > Failed asserting that null matches expected 10. > > /tmp/autopkgtest.qBADD9/build.ebg/src/Horde_Db-2.4.0/test/Horde/Db/Adapter/MysqlBase.php:260 > > 2) Horde_Db_Adapter_Pdo_MysqlTest::testColumns > Failed asserting that null matches expected 10. > > /tmp/autopkgtest.qBADD9/build.ebg/src/Horde_Db-2.4.0/test/Horde/Db/Adapter/MysqlBase.php:260 > > > > The relevant test is: > > public function testColumns() > { > $col = parent::testColumns(); > $this->assertEquals(10, $col->getLimit()); > $this->assertEquals(true, $col->isUnsigned()); > $this->assertEquals('int(10) unsigned', $col->getSqlType()); > } > > $col->getLimit() is expected to be, for a column defined as "int(10) > unsigned", 10. However, according to MySQL's release notes > (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-19.html): > > "Display width specification for integer data types was deprecated in > MySQL 8.0.17, and now statements that include data type definitions > in their output no longer show the display width for integer types..." > > There are some exceptions but my understanding is that since int(10) > doesn't make sense for MySQL, if you define a table like that MySQL > will accept it, but a data dictionary query will not return the > "(10)" part any more. > > So the test's assumption is now wrong. It's not obvious to me if > adjusting the test will leave the assumption present in other parts > of production code. > > Downstream bug: > https://bugs.launchpad.net/ubuntu/+source/php-horde-db/+bug/1861099
Attachment
Watch this ticket

Saved Queries