From a06ea2e1cd4165c94f2a41028898de4e4096f743 Mon Sep 17 00:00:00 2001 From: BOHA Date: Tue, 9 Jun 2026 10:37:40 +0200 Subject: [PATCH] =?UTF-8?q?docs(orders):=20plan=20fix=20=E2=80=94=20no=20m?= =?UTF-8?q?anual=20migration=20SQL=20edits=20(code-level=20numbering=20def?= =?UTF-8?q?aults)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- .../plans/2026-06-09-issued-orders.md | 28 ++++++++----------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/docs/superpowers/plans/2026-06-09-issued-orders.md b/docs/superpowers/plans/2026-06-09-issued-orders.md index 119973a..6e7ea97 100644 --- a/docs/superpowers/plans/2026-06-09-issued-orders.md +++ b/docs/superpowers/plans/2026-06-09-issued-orders.md @@ -133,24 +133,20 @@ npx prisma migrate dev --name issued_orders Expected: a new folder `prisma/migrations/_issued_orders/` is created and applied to the dev `app` DB. Open `migration.sql` and confirm it `CREATE TABLE issued_orders`, `CREATE TABLE issued_order_items`, and `ALTER TABLE company_settings ADD COLUMN issued_order_number_pattern …` / `… issued_order_type_code …`. -- [ ] **Step 5: Give the two new settings columns their defaults in the migration SQL** +- [ ] **Step 5: Confirm the migration needs NO manual SQL edits** -Edit the generated `migration.sql` so the two new `company_settings` columns carry their baseline defaults (production needs them without a manual step). Ensure these statements are present (adjust to match the generated column DDL — `ALTER` the defaults if Prisma created them nullable without a default): +Do **not** hand-edit the generated `migration.sql`. The two new `company_settings` +columns are nullable with **no DB default** — exactly like the existing +`order_number_pattern` / `invoice_number_pattern` / `*_type_code` columns. The +baseline values are supplied **in code** by the numbering service (Task 2: +`settings?.issued_order_number_pattern || DEFAULT_ISSUED_ORDER_PATTERN` and +`settings?.issued_order_type_code || "72"`), so a NULL column resolves correctly +on dev, test, and prod with zero migration surgery. -```sql -ALTER TABLE `company_settings` - ADD COLUMN `issued_order_number_pattern` VARCHAR(100) NULL DEFAULT '{YY}{CODE}{NNNN}', - ADD COLUMN `issued_order_type_code` VARCHAR(10) NULL DEFAULT '72'; - -UPDATE `company_settings` - SET `issued_order_number_pattern` = '{YY}{CODE}{NNNN}' - WHERE `issued_order_number_pattern` IS NULL; -UPDATE `company_settings` - SET `issued_order_type_code` = '72' - WHERE `issued_order_type_code` IS NULL; -``` - -Re-apply if you edited after generation: `npx prisma migrate dev` (it will detect the edited pending migration is already applied; if it reports drift, `npx prisma migrate reset` on the **dev** DB is acceptable since dev data is disposable — never on prod). +Editing an **already-applied** migration would change its checksum and make the +next `prisma migrate dev` demand a reset — avoid that entirely. Just verify the +generated `migration.sql` looks sane (two `CREATE TABLE`s, the enum, and two +`ADD COLUMN`s) and move on. - [ ] **Step 6: Regenerate the Prisma client**