Integer fields never match stored schema in MySQL 8

[Cheddam]

Affected Version

4.x (potentially 3.x also, untested though)

Description

When running Silverstripe against MySQL 8, all integer fields (including IDs and 'Booleans') are ALTERed during every dev/build. This is caused by MySQL 8 no longer storing the specified display width attribute (the (11) in int(11)); they've in fact deprecated this functionality for integer fields:

As of MySQL 8.0.17, the display width attribute is deprecated for integer data types and support for it will be removed in a future MySQL version.

The display width attribute, so far as I can tell, is only useful when paired with ZEROFILL, which prepends 0s to values when they are stored, so this doesn't have a lot of relevance in most Silverstripe projects. Unfortunately, simply dropping the display width attributes from our default integer types inverts the issue to affect previous MySQL versions, as they always return a default display width value.

Here's an excerpt of the output I see from every dev/build:

Field File.ID: changed to int(11) not null auto_increment (from int not null auto_increment)
Field File.Version: changed to int(11) not null default '0' (from int not null default '0')
Field File.ShowInSearch: changed to tinyint(1) unsigned not null default '1' (from tinyint unsigned not null default '1')

Steps to Reproduce

1. Configure an environment with MySQL 8.0.17 or later (not sure if earlier patch releases trigger this behaviour; I personally tested with 8.0.19)
2. Run dev/build to populate the database
3. Run dev/build again (and again, and again)

Expected output: No DB changes
Observed output: Repeated integer column schema changes like the example above.

Pull requests

• FIX Don't use int width for mysql >= 8.0.17 #9453 #9749

[OldStarchy]

@Cheddam I guess this issue should be closed now that #9749 is merged.