Would appreciate any DBA feedback on this, especially about the datatype being used for gb_target (as we can choose the appropriate one to use).

The equivalent in column in the block_target table is bl_user_text. This is defined as a VARBINARY(255). Additionally, the globaluser has the column gu_name which is VARBINARY(255) too. That suggests going with the binary type as the column would be the appropriate choice.

Timescales on this are likely that we will not start significant work on this for at least several weeks, possibly a few months. So no rush on any feedback. Thanks in advance

On the type: We always use varbinary and it's standardized while abstraction. In most case it won't even make a difference since our charset is binary in the first place.

If you're just renaming the field, I discourage it since any schema change adds a lot of overhead from the work for the DBAs, code maintenance, etc. If you're doing something else and bundling the rename, that's fine.

There was a default that we wanted to remove, but that doesn't necessarily require a schema change. The only other change was to make the type be the same, but I thought it isn't possible to change the data type while there is data in the column.

Maybe to clarify, is it possible to fix the data type without breaking the data in column? If not possible, do we care about having the schema drift remain forever?

So what's the current data type and what's the desired one?

In T414211#11519748, @Marostegui wrote:

So what's the current data type and what's the desired one?

The current data type is:

• On WMF wikis it is varbinary(255) NOT NULL DEFAULT ''
• In tables-generated.sql it is VARCHAR(255) NOT NULL

Ideally I want to make WMF wikis and tables-generated.sql use the same type to avoid the drift (though have no preference either way on what data type is chosen). However, I think I am proposing the data type be VARCHAR(255) NOT NULL on WMF wikis and tables-generated.sql to avoid the need for a schema change in the extension

If this schema drift of the data type should be ignored from the point of view of DBA, then I'd only suggest removing the default from the column

https://www.mediawiki.org/wiki/Manual:Schema_changes

Instead of VARCHAR or CHAR, use VARBINARY or BINARY (otherwise you have to deal with encodings in databases)

In T414211#11520606, @Ladsgroup wrote:

https://www.mediawiki.org/wiki/Manual:Schema_changes

Instead of VARCHAR or CHAR, use VARBINARY or BINARY (otherwise you have to deal with encodings in databases)

Okay, then I propose to:

• Make a schema change in the extension to alter the type of gb_address in globalblocks to VARBINARY from VARCHAR
• Apply this schema change, which has the effect of removing the default on WMF wikis without changing the data type

Does this make sense? If so, I can update the tasks to reflect this

Sounds good to me!

In T414211#11520650, @Dreamy_Jazz wrote:

In T414211#11520606, @Ladsgroup wrote:

https://www.mediawiki.org/wiki/Manual:Schema_changes

Instead of VARCHAR or CHAR, use VARBINARY or BINARY (otherwise you have to deal with encodings in databases)

Okay, then I propose to:

• Make a schema change in the extension to alter the type of gb_address in globalblocks to VARBINARY from VARCHAR
• Apply this schema change, which has the effect of removing the default on WMF wikis without changing the data type

Does this make sense? If so, I can update the tasks to reflect this

That looks good to me

Change #1227810 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Standardise type of gb_address column in globalblocks table

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

Change #1227810 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Standardise type of gb_address column in globalblocks table

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