So tinyint(4) happens on:

s1, s2, some wikis of s5 (the old ones, as s5 also holds some new ones), s6, s7, s8.

s3 is on going

s3 has tinyint(4) on all the wikis but the most recent ones, which is a total of 23 out of 905.
It is probably less time consuming (and way less risky) to change this on code, and only alter those affected 23 + a few on s5 wikis.

@Ladsgroup would this work for you?

Sure thing! I can apply it with the abstract schema change (since the schema of that table itself is abstracted now) to make the patch quick and easy ^_^

In T265321#6537734, @Marostegui wrote:

So tinyint(4) happens on:

s1, s2, some wikis of s5 (the old ones, as s5 also holds some new ones), s6, s7, s8.

s3 is on going

s2 was clean, my bad when checking.

@Ladsgroup s3 and s5 are fixed.
The only pending thing is to push the patch to change this on code, so future wikis get the (4).

Sure, I'm just waiting to finish the abstract schema change system merged so doing the patch would be several times easier. Hopefully soon.

Unsubscribing DBA. Please add us back if you need any further assistance or are aware of new wikis created between the time of this comment and final code deployment.

Interesting trivia: MySQL is going to deprecate definition of length for numeric values: https://dev.mysql.com/worklog/task/?id=13127 We should stop defining them in the first place.

Mentioned in SAL (#wikimedia-operations) [2020-10-19T12:15:02Z] <marostegui> Deploy schema change on smnwiki T265321 T264900

In T265321#6559774, @jcrespo wrote:

Interesting trivia: MySQL is going to deprecate definition of length for numeric values: https://dev.mysql.com/worklog/task/?id=13127 We should stop defining them in the first place.

It's something we seemingly only do in a minority. At least in MW core, only on TINYINT, in two cases. 17 other tinyint in tables.sql don't do it

It's something we seemingly only do in a minority. At least in MW core, only on TINYINT, in two cases. 17 other tinyint in tables.sql don't do it

Not sure about this, but we could switch to BOOLEAN/BOOL in those cases where it would make sense. It is not a real type but maps to TINYINT(1). It could maybe useful for deprecation and semantically, but could cause other issues, so just mentioning as a possibility. Depends on how abstract schema handles it?

Change 641170 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/core@master] Increase size of ipblocks_restrictions.ir_type

https://gerrit.wikimedia.org/r/641170

Change 641170 merged by jenkins-bot:
[mediawiki/core@master] Increase size of ipblocks_restrictions.ir_type

https://gerrit.wikimedia.org/r/641170

this is not done in testcommonswiki (s4)

It is already tinyint there:

+-----------------------+---------------------------------------------------------------------------------------------------------------
| Table                 | Create Table
+-----------------------+---------------------------------------------------------------------------------------------------------------
| ipblocks_restrictions | CREATE TABLE `ipblocks_restrictions` (
  `ir_ipb_id` int(11) NOT NULL,
  `ir_type` tinyint(1) NOT NULL,
  `ir_value` int(11) NOT NULL,
  PRIMARY KEY (`ir_ipb_id`,`ir_type`,`ir_value`),
  KEY `ir_type_value` (`ir_type`,`ir_value`)
) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED |

Keep in mind that the (X) is just a display value, it has no effect on the data.
As the table is empty, I have altered it anyways.

In T265321#6688675, @Marostegui wrote:

It is already tinyint there:

+-----------------------+---------------------------------------------------------------------------------------------------------------
| Table                 | Create Table
+-----------------------+---------------------------------------------------------------------------------------------------------------
| ipblocks_restrictions | CREATE TABLE `ipblocks_restrictions` (
  `ir_ipb_id` int(11) NOT NULL,
  `ir_type` tinyint(1) NOT NULL,
  `ir_value` int(11) NOT NULL,
  PRIMARY KEY (`ir_ipb_id`,`ir_type`,`ir_value`),
  KEY `ir_type_value` (`ir_type`,`ir_value`)
) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED |

Keep in mind that the (X) is just a display value, it has no effect on the data.
As the table is empty, I have altered it anyways.

Thanks. It's mostly about keeping the drift report less noisy, not that it matters. Sorry for the noise.