boha_admin/app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 26 Wiki Activity

docs(orders): plan fix — no manual migration SQL edits (code-level numbering defaults)

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
BOHA
2026-06-09 10:37:40 +02:00
parent 15a2da38cc
commit a06ea2e1cd
1 changed files with 12 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/superpowers/plans/2026-06-09-issued-orders.md
View File

@@ -133,24 +133,20 @@ npx prisma migrate dev --name issued_orders
Expected: a new folder `prisma/migrations/<timestamp>_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 …`. Expected: a new folder `prisma/migrations/<timestamp>_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 Editing an **already-applied** migration would change its checksum and make the
ALTER TABLE `company_settings` next `prisma migrate dev` demand a reset — avoid that entirely. Just verify the
ADD COLUMN `issued_order_number_pattern` VARCHAR(100) NULL DEFAULT '{YY}{CODE}{NNNN}', generated `migration.sql` looks sane (two `CREATE TABLE`s, the enum, and two
ADD COLUMN `issued_order_type_code` VARCHAR(10) NULL DEFAULT '72'; `ADD COLUMN`s) and move on.
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).
- [ ] **Step 6: Regenerate the Prisma client** - [ ] **Step 6: Regenerate the Prisma client**