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

Bug #1861099 reported by Robie Basak on 2020-01-28
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Horde
Unknown
Unknown
mysql-8.0 (Ubuntu)
Undecided
Unassigned
Eoan
Undecided
Unassigned
php-horde-db (Ubuntu)
Undecided
Robie Basak
Eoan
Undecided
Unassigned

Bug Description

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

--

Related branches

Robie Basak (racb) wrote :

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.

Changed in php-horde-db (Ubuntu):
status: New → Triaged
Robie Basak (racb) wrote :

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.

tags: added: regression-update
Changed in mysql-8.0 (Ubuntu):
status: New → Triaged
Changed in mysql-8.0 (Ubuntu Eoan):
status: New → Triaged
Changed in php-horde-db (Ubuntu Eoan):
status: New → Triaged
Robie Basak (racb) wrote :

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) on 2020-01-28
Changed in php-horde-db (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Robie Basak (racb)
Robie Basak (racb) wrote :

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

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

Robie Basak (racb) on 2020-01-29
Changed in php-horde-db (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in php-horde-db (Ubuntu):
status: Fix Committed → Fix Released
Changed in mysql-8.0 (Ubuntu):
status: Triaged → Invalid
Changed in mysql-8.0 (Ubuntu Eoan):
status: Triaged → Invalid
Changed in php-horde-db (Ubuntu Eoan):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.