[db] Change the primary key of the d_b_oauth_auth_code_entry table

[andrew-farries]

Description

Following on from #13524 which added the uid column to the d_b_oauth_auth_code_entry table and #13577 which ensured that all new records set the uid field, this PR changes to the primary key to the uid column (and renames it to id).

Related Issue(s)

Part of #9198

How to test

1. Run the local-companion app local-app against the preview environment:

GITPOD_HOST=https://af-make-uib1daf36a03.preview.gitpod-dev.com ./local-app test

2. Run through the auth flow.
3. See that the new rows in the d_b_oauth_auth_code_entry table have their id column set.

Release Notes

NONE

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[werft-gitpod-dev-com]

started the job as gitpod-build-af-make-uid-column-pk.16 because the annotations in the pull request description changed
(with .werft/ from main)

[easyCZ]

What do we expect to happen when the migrations take place but existing instances are still running with PK set previously? I believe this will work fine, unless the @PrimaryGeneratedColumn() affects how the values are determined (and possibly generated)

/hold for Q

[andrew-farries]

What do we expect to happen when the migrations take place but existing instances are still running with PK set previously? I believe this will work fine, unless the @PrimaryGeneratedColumn() affects how the values are determined (and possibly generated)

Not sure I understand the question. Do you mean is it possible to perform this key switch against a real table with data? If so, this migration has been run against such a table as part of testing this.

[easyCZ]

When the migrations run, the application that's running will still have the @PrimaryGeneratedColumn() annotation - is this a problem? This could result in a generated value being written to the id property.

[andrew-farries]

I think the table is infrequently used enough that we can take the chance of a write to the table happening during the migration. I'm not sure how we would avoid the problem anyway, actually.

[geropl]

I think the table is infrequently used enough that we can take the chance of a write to the table happening during the migration.

I generally agree with the sentiment that we have compare effort and value. But we have to take into account that things happen, e.g.:

• one of our assumptions about transactionality of the migration is wrong, and it fails mid-flight, leaving it up to us to fix the situation manually
• this happens to get rolled out together with another, later migration that takes a lot of time (say, ~15mins) to execute

In both situations, suddenly the old code is broken because of this, causing an incident.

I'm not sure how we would avoid the problem anyway, actually.

I think we could decouple the migration from the code change, no? In a way where we:

1. fill both, uid and id from code
2. roll out the PK change (by setting id = uid instead of rename, or doing a three-way-swap), and stop filling uid in code
3. drop the old uid column altogether

Might be a little bit more work, but would make me feel much safer. 👍

[andrew-farries]

Closing this in favour of the safer approach mentioned by @gero in this comment.

#13616 is the first step towards that.