https://drift-tracker.toolforge.org/report/core/ shows a schema drift for:
Mismatching field type of text.old_flags
on s3, s7
The field is a tinyblob since addition 64ac6b8e775dd8582ea9cc5f24235488f076c5b3
But wmf production is using varbinary on some sections:
```
root@db1112.eqiad.wmnet[thwikiquote]> show create table text\G
*************************** 1. row ***************************
Table: text
Create Table: CREATE TABLE `text` (
`old_id` int(8) unsigned NOT NULL AUTO_INCREMENT,
`old_text` mediumblob NOT NULL,
`old_flags` varbinary(255) NOT NULL,
PRIMARY KEY (`old_id`)
) ENGINE=InnoDB AUTO_INCREMENT=42791 DEFAULT CHARSET=binary PACK_KEYS=1
1 row in set (0.001 sec)
```
Maybe the `varbinary(255)` is a better datatype from the production view?
A new task is should be used to request a code change and later adjust the other sections for the newest schema with this task
There is no ready ALTER statement in the commit history.
```lang=sql
ALTER TABLE /*_*/text
CHANGE old_flags old_flags TINYBLOB NOT NULL;
```
# **ALTERs to run:** see above
# **Where to run those changes:** s3, s7 - list of wikis needs to be created
# **When to run those changes:** any time
# **If the schema change is backwards compatible:** Yes
# **If the schema change has been tested already on some of the test/beta wikis:** beta cluster is running with the new schema
# **if the data should be made available on the labs replicas and/or dumps:** no change of the existing rules
Progress
[x] s1 (not needed)
[x] s2 (not needed)
[x] s3
[x] s4 (not needed)
[] s5: Done except master
[] s6
[x] s7
[x] s8 (not needed)