Blocked on doing T349486: Change temporary user pattern configuration on beta to match the updated prefix and checking everything goes ok.

Are these tables supposed to be created already?

root@db1227.eqiad.wmnet[centralauth]> show tables like 'global_user_autocreate_%';
Empty set (0.001 sec)

root@db1227.eqiad.wmnet[centralauth]>

root@db1227.eqiad.wmnet[eswiki]> show tables like 'user_autocreate_serial%';
Empty set (0.001 sec)

root@db1227.eqiad.wmnet[eswiki]>

I'm sure we created user_autocreate_serial (Tim did it) on wikis. Let me check.

I also can't seem to find the central auth table and the table doesn't seem to exist on enwiki. Will wait for @Ladsgroup to check. Happy to create the tables myself given that it isn't usually for the DBAs to create the table (per https://wikitech.wikimedia.org/wiki/Creating_new_tables ). From what I can tell, this ticket would still need to proceed at some point as the core patch creates the table without this new column.

If the tables aren't created, can't we create them with the new columns from scratch? It will save time

In T354700#9472320, @Marostegui wrote:

If the tables aren't created, can't we create them with the new columns from scratch? It will save time

My concern was that the process described at https://wikitech.wikimedia.org/wiki/Creating_new_tables for creating a table in core uses one SQL file, so if we need to use the SQL files listed in maintenance/archives then we could only create the table without the uas_year column.

Is it possible to run the ALTER in this case using sql.php? I had assumed that it was not okay to do an ALTER on production in any situation.

If it is not okay to do this, perhaps whoever creates the table could create a new SQL file that has the uas_year column added. I was unsure if this was allowed considering it is running SQL that adds a table that hasn't received a +2.

nah, just put the sql file in home dir and call it with full path. That's exactly what I did last week.

In T354700#9472343, @Ladsgroup wrote:

nah, just put the sql file in home dir and call it with full path. That's exactly what I did last week.

Thanks. I now know for the future.

Therefore, as long the table doesn't exist anywhere we can probably close this ticket?

It's also probably prudent to add "CREATE TABLE IF NOT EXISTS" to avoid mess and potentially broken replication.

In T354700#9472345, @Ladsgroup wrote:

It's also probably prudent to add "CREATE TABLE IF NOT EXISTS" to avoid mess and potentially broken replication.

+1

Mentioned in SAL (#wikimedia-operations) [2024-01-29T11:39:49Z] <Dreamy_Jazz> T354700 - Ran mwscript maintenance/sql.php --wiki=testwiki ~/T354700-create-table.sql

Running the following SQL on all wikis:

CREATE TABLE IF NOT EXISTS user_autocreate_serial (
  uas_shard INT UNSIGNED NOT NULL,
  uas_value INT UNSIGNED NOT NULL,
  uas_year SMALLINT UNSIGNED NOT NULL,
  PRIMARY KEY(uas_shard, uas_year)
);

Mentioned in SAL (#wikimedia-operations) [2024-01-29T11:45:08Z] <Dreamy_Jazz> sql.php finished for T354700

Running the following SQL for the centralauth DB:

CREATE TABLE IF NOT EXISTS global_user_autocreate_serial (
  uas_shard INT UNSIGNED NOT NULL,
  uas_value INT UNSIGNED NOT NULL,
  uas_year SMALLINT UNSIGNED NOT NULL,
  PRIMARY KEY(uas_shard, uas_year)
);

Mentioned in SAL (#wikimedia-operations) [2024-01-29T11:53:18Z] <Dreamy_Jazz> Running mwscript maintenance/sql.php --wiki=testwiki --wikidb=centralauth ~/T354700-create-table-global.sql for T354700

@Dreamy_Jazz there are two statements on each schema change that say: When to run those changes: not yet (but blocks temp accounts deploy to testwiki) is that still the case? If yes, maybe let's leave this as stalled, if not, let's change them so it is not confusing :)

There is no way to QA this without access to production DBs. I would suggest that QA be skipped for this task, but moving into the Needs QA column for QA to decide either way.

In T354700#9493632, @Marostegui wrote:

@Dreamy_Jazz there are two statements on each schema change that say: When to run those changes: not yet (but blocks temp accounts deploy to testwiki) is that still the case? If yes, maybe let's leave this as stalled, if not, let's change them so it is not confusing :)

I've changed it to be at any time and I updated the ticket description.

My understanding is that these were marked as not for now because we wanted to test that the schema changes worked on betawikis. The changes were deployed to beta and the new uas_year column is working (tested this last week before I went OOO), so that part is now complete.

Could you clarify why this task is resolved? As far as I know these columns aren't part of production yet. Are them not needed in the end?

In T354700#9500939, @Marostegui wrote:

Could you clarify why this task is resolved? As far as I know these columns aren't part of production yet. Are them not needed in the end?

In T354700#9493625 I show that testwiki and centralauth have the uas_year column. I added the column to the create table statement so the column was added as part of creating the tables. The create table statement for the core table was run on all wikis as I used foreachwiki.

If I've missed a wiki, please let me know.

Ah ok, you created them as part of the table creation statement, I was missing that bit. Yep, testwiki and centralauth have them. Thanks for clarifying