php-horde-db autopkgtests fail on MySQL 8.0.19 and later

[Robie Basak]

The errors 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

--

[Robie Basak (racb)]

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.

[Robie Basak (racb)]

Since Eoan was updated to 8.0.19 also, this is a behavioural change that might also affect users of a stable release, so I think the regression-updates tag is warranted for tracking purposes. I'm not sure if any action for Eoan is advisable however. Even though the behavioural change is certain, it's not clear if there are any users actually affected, and reversing the change could lead to other problems.

[Robie Basak (racb)]

php-horde-db is a library used for database access by Horde applications. The source package generates only a binary package of the same name. Nothing Build-Depends on php-horde-db. All binary packages currently in focal-proposed are generated from the following (29) source packages:

php-horde
php-horde-activesync
php-horde-alarm
php-horde-ansel
php-horde-auth
php-horde-cache
php-horde-content
php-horde-core
php-horde-gollem
php-horde-group
php-horde-history
php-horde-imap-client
php-horde-kronolith
php-horde-lock
php-horde-mnemo
php-horde-nag
php-horde-passwd
php-horde-perms
php-horde-prefs
php-horde-rdo
php-horde-sesha
php-horde-sessionhandler
php-horde-share
php-horde-token
php-horde-trean
php-horde-turba
php-horde-vfs
php-horde-whups
php-horde-wicked

I retrieved all of these and grepped for "getLimit" and found zero hits. Exploring lib/Horde/Db/Adapter/Base/Column.php and lib/Horde/Db/Adapter/Base/ColumnDefinition.php from src:php-horde-db, it seems that the parsing is _extractLimit, stored in a private member variable called _limit, and accessed only via public method getLimit.

I conclude that there do not appear to be any actual users of this API method inside Horde itself, then from the perspective of php-horde-db, while the test is correctly failing, the behaviour change in MySQL, as far as I can tell, will not affect Horde's behaviour. It therefore should be OK to disable or modify the test in php-horde-db for the purposes of the archive.

There may be other consumers outside the archive of php-horde-db's getLimit API, or of MySQL's behaviour directly, that remain affected.

[Robie Basak (racb)]

> All binary packages currently in focal-proposed are generated...

All binary packages that depend on php-horde-db, that is, are generated...

[Launchpad Janitor (janitor)]

This bug was fixed in the package php-horde-db - 2.4.0-4ubuntu4

---------------
php-horde-db (2.4.0-4ubuntu4) focal; urgency=medium

  * d/p/mysql-integer-column-limit.patch: adjust test for MySQL >= 8.0.19
    behaviour (LP: #1861099).

 -- Robie Basak <email address hidden> Tue, 28 Jan 2020 14:32:30 +0000