Add migration_status column in repositories table

Context

As part of Phase 2 of the gradual migration plan, the routing logic which determines whether a repository should follow the new or old code path will change, requiring knowledge of the migration status of the repository.

Initially, to support phase 2 routing, we will only need to implement the native status (which means a repository has been created directly on the new code path/metadata DB) for all new repositories, but we'll need to support several migration statuses afterwards: #510 (closed)

Proposal

During phase 1, we should add the migration_status column to the repositories table. We should do this in a non-blocking fashion as follows:

  1. Release N:
    1. Add new migration_status column (text) to repositories table, without a DEFAULT or NOT NULL constraint:
      ALTER TABLE repositories ADD COLUMN IF NOT EXISTS migration_status text;
      ALTER TABLE repositories ADD CONSTRAINT check_repositories_migration_status_length CHECK ((char_length(migration_status) <= 255)) NOT VALID;
      ALTER TABLE repositories VALIDATE CONSTRAINT check_repositories_migration_status_length;
    2. Default migration_status to native on the application side;
  2. Release N+1:
    1. Backfill migration_status on rows created before N (migration_status = NULL), setting them to native. On large tables this would be ideally done in a background migration, but we lack such feature for now (#221 (closed)) and the table is pretty small, so we can do a one time update:
      UPDATE repositories SET migration_status='native' WHERE migration_status IS NULL;
  3. Release N+2:
    1. Add non-blocking NOT NULL constraint:
      ALTER TABLE repositories ADD CONSTRAINT check_repositories_migration_status_not_null CHECK (migration_status IS NOT NULL) NOT VALID;
      ALTER TABLE repositories VALIDATE CONSTRAINT check_repositories_migration_status_not_null;

Concerns

It's better to address this earlier in phase 1, so we can evaluate that the application code is correctly marking new repositories as native before phase 2 where this information is needed in critical application logic.

Edited by João Pereira