| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T254646 Reconsidering how we name things | |||
| Open | None | T277942 Address Voice and Tone issues in GlobalBlocking | |||
| Resolved | None | T277978 Address Voice and Tone issues in WikimediaMaintenance | |||
| Declined | None | T277994 Rename global_block_whitelist table |
Event Timeline
How much of a pain is this going to be?
Can we rename the table, and then have a temporary view for the old name?
It can be a huge pain. I wouldn't like to have to deal with views in production to be honest.
Fair enough.
Annoyingly, global_block_whitelist exists on every SUL wiki, but I imagine in most cases it's going to be small (4 rows on enwiki and dewiki, 3 on commonswiki), so renaming should be relatively quick...
Needs a bit more of a plan of action
Renaming it on the master should be instant, the problem is if it is accessed a lot on the slaves they could run into metada locking issues.
Is it read a lot?
I'm not sure.
It would look like from looking at the code that it is probably mostly only called when there's a blocked user/ip doing actions (ie there's a row in the globalblocks table that affects the user). And also when viewing lists of global blocks etc too.
I bet this results in "it is read more than you would expect"
I'm also thinking how would this be deployed? How many wikis would it need to be done in?
It is obviously impossible to do it exactly at the same time on all of them.
What's the main goal of renaming it? Cause I think it is going to cause lots of headaches and possibly breakages.
@Reedy I am going to close this as declined as the risks are pretty high and the deployment plan is also pretty much impossible if we don't set a global read-only (reopen if you still think we need to consider this).
We could consider moving the global_block_whitelist table to be a central table, and then renaming the table as part of the move? Alternatively, we could have two tables for a while to migrate the data and then reads?
It is possible but the amount of work is unconventional and must be done from mw not databases. With a lot of burning fires, I'm not sure I can do it but won't stop anyone if they are willing to do it from mw side.