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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14984
------------------------------------------------------------------------------
  Ticket             | 14984
  Created By         | robie.basak at canonical.com
  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
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


robie.basak at canonical.com (2020-01-28 12:05) wrote:

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