From 4c4fa645b17b94a66cd23d36453b77b58fd4f07b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Thu, 14 May 2026 22:36:33 +0200 Subject: [PATCH] docs(db): rewrite Migration 0057 PG11+ default-backfill comment MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The original comment claimed that `DEFAULT 0` "only applies to *new* inserts on PostgreSQL — existing rows are not backfilled". That's wrong for PG11+: the fast-path `ADD COLUMN ... DEFAULT` materialises the default for every existing row in O(1) time without rewriting the table. The comment confused future readers about why the Wizard mount treats `NULL` as 0 (defensive against the legacy ambiguity, not because of any general PG behaviour). Rewrite to match reality, and point at Migration 0060 as the follow-on that flips the column to NOT NULL. Fix-O / code-M8. --- .../migrations/0057_user_onboarding_step/migration.sql | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/prisma/migrations/0057_user_onboarding_step/migration.sql b/prisma/migrations/0057_user_onboarding_step/migration.sql index de990f6d8..c84708710 100644 --- a/prisma/migrations/0057_user_onboarding_step/migration.sql +++ b/prisma/migrations/0057_user_onboarding_step/migration.sql @@ -14,10 +14,12 @@ -- 4 = done (success screen; same write that flips -- `onboarding_completed_at` from NULL to NOW()) -- --- Default 0 keeps the column non-null in practice for every new user, --- while existing pre-W14b rows stay NULL (because the `DEFAULT 0` --- only applies to *new* inserts on PostgreSQL — existing rows are not --- backfilled). Wizard mount code treats NULL as 0. +-- Existing rows are backfilled to 0 by PostgreSQL's fast-path +-- `ADD COLUMN ... DEFAULT` (PG11+), which materialises the default +-- without rewriting the table — every pre-W14b user lands at step 0 +-- in O(1) time. The column ships nullable purely so the DDL stays +-- additive on every replica; Migration 0060 follows up by flipping +-- it to NOT NULL once the deploy has rolled. -- -- The `IF NOT EXISTS` guards make the migration idempotent — if the -- column landed via a prior dev-DB hand-edit, the migration still