lablup / lablup/backend.ai

[Domain] Swap domains PK from name to id and consolidate Alembic heads

Open
#11,617 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
670
Forks
183
Avg merge
17h 7m
Merged PRs (30d)
358

Description

Goal

Atomically swap the ``domains`` primary key from ``name`` to ``id`` and demote ``name`` to a UNIQUE column. Consolidate the multiple Alembic heads produced by the 10 parallel referencing-table stories (BA-6123 … BA-6132) into a single linear chain so this PK swap is the final domain-side schema change.

Background

BA-6044 added a UUID ``id`` column to ``domains`` as a UNIQUE alternate key while leaving ``name`` as the primary key. The 10 parallel stories under BA-6043 (one per referencing table) each moved their foreign key reference from ``domains.name`` to ``domains.id``. After all 10 stories merge, no foreign key constraint targets ``domains.name`` anymore, so dropping the PK on ``name`` is safe.

Without the FK migrations, attempting the PK swap fails: PostgreSQL refuses to drop a unique / primary-key constraint that is the referenced index of a live foreign key. This story therefore only runs once every referencing-table story has been merged.

Scope

1. Alembic — multi-head consolidation: each of BA-6123 … BA-6132 creates a revision whose ``down_revision`` is the pre-fork head (``fdc9d6ac49b4`` at the time of this writing). After they all merge, the migration chain has 10 heads. This story adds a single ``alembic merge`` revision that has all 10 heads as parents and produces a single new head.

2. Alembic — PK swap: in the same merge revision (or in a follow-on revision stacked on top of it):

- ``ALTER TABLE domains DROP CONSTRAINT pk_domains;``

- ``ALTER TABLE domains DROP CONSTRAINT uq_domains_id;`` (the alternate UNIQUE added by BA-6044 becomes redundant once ``id`` is PK)

- ``ALTER TABLE domains ADD CONSTRAINT pk_domains PRIMARY KEY (id);``

- ``ALTER TABLE domains ADD CONSTRAINT uq_domains_name UNIQUE (name);``

- Downgrade reverses.

3. ORM: ``DomainRow`` flips ``id`` to ``primary_key=True`` and demotes ``name`` to ``nullable=False, unique=True``.

4. ``Updater[DomainRow]`` / ``Purger[DomainRow]`` / ``session.get(DomainRow, …)`` call sites: the PK is now ``DomainID``, so ``pk_value`` must be ``DomainID`` rather than the domain name string. Affected entry points convert client-supplied ``domain_name`` via ``ResolveDomainIDByNameAction``: ``api/rest/domain/handler.py`` + ``api/rest/domain/adapter.py::build_updater``, ``api/adapters/domain/adapter.py::admin_update``, ``api/gql_legacy/domain.py::ModifyDomainNode`` and ``ModifyDomain``.

5. Tests: domain repository / service tests that construct ``Updater[DomainRow](pk_value=...)`` switch to passing a ``DomainID``.

Dependencies

- Hard-blocks on all 10 stories: BA-6123, BA-6124, BA-6125, BA-6126, BA-6127, BA-6128, BA-6129, BA-6130, BA-6131, BA-6132.

- Should land before BA-6122 (legacy column drop and search-filter / propagation cleanup) and BA-6047 (RBAC migration) so those work against the final ``id``-based PK.

Out of scope

- Adding ``domain_id`` columns and moving FKs on the 10 referencing tables — covered by BA-6123 … BA-6132.

- Dropping legacy ``domain_name`` / ``domain`` columns and the ``sgroups_for_domains`` composite UNIQUE relocation — BA-6122.

- RBAC migration — BA-6047.

JIRA Issue: BA-6046

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.