6.0.0-git
2020-02-20

[#14984] Horde Database Libraries tests fail against fail on MySQL 8.0.19 and later
Summary Horde Database Libraries tests fail against fail on MySQL 8.0.19 and later
Queue Horde Framework Packages
Type Bug
State Unconfirmed
Priority 3. High
Owners
Requester robie.basak (at) canonical (dot) com
Created 2020-01-28 (23 days ago)
Due
Updated 2020-01-28 (23 days ago)
Assigned
Resolved
Milestone
Patch No

History
2020-01-28 12:05:06 robie (dot) basak (at) canonical (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ Horde Database Libraries tests fail against fail on MySQL 8.0.19 and later
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
Reply to this 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

Saved Queries