veza/docs/MIGRATIONS.md
senke 83ed4f315b
Some checks failed
Backend API CI / test-unit (push) Failing after 0s
Backend API CI / test-integration (push) Failing after 0s
Frontend CI / test (push) Failing after 0s
Storybook Audit / Build & audit Storybook (push) Failing after 0s
chore(release): v0.602 — Payout, Dette Technique & Tests E2E
- Stripe Connect: onboarding, balance, SellerDashboardView
- Interceptors: auth.ts, error.ts extracted, facade
- Grafana: dashboards enriched (p50, top endpoints, 4xx, WS, commerce)
- E2E commerce: product->order->review->invoice
- SMOKE_TEST_V0602, RETROSPECTIVE_V0602, PAYOUT_MANUAL
- Archive V0_602 scope, V0_603 placeholder, SCOPE_CONTROL v0.603
- Fix sanitizer regex (Go no backreferences)
- Marketplace test schema: product_licenses, product_images, orders, licenses
2026-02-23 22:32:01 +01:00

43 lines
1.4 KiB
Markdown

# Database Migrations
## Overview
Veza uses SQL migrations stored in `veza-backend-api/migrations/`. Migrations are applied in order by filename (lexicographic sort).
## Migration Naming
- Format: `NNN_description.sql` (e.g. `101_product_reviews.sql`)
- Use snake_case for descriptions
- Down migrations (rollback): `NNN_description_down.sql` when needed
## Squash Script
The `scripts/squash_migrations.sh` script generates a baseline SQL file that concatenates all migrations into a single file. This is useful for:
- Fresh database setup
- Creating a clean baseline for new environments
- Versioned releases (e.g. `baseline_v0601.sql`)
### Usage
```bash
# From project root
./scripts/squash_migrations.sh
```
Output: `veza-backend-api/migrations/baseline_v0601.sql`
### Procedure
1. Run the script after adding new migrations
2. Update the version in the script (e.g. `baseline_v0601.sql`) for each release
3. Update the migration range comment (e.g. `001-113`) to reflect the latest migration number
4. The baseline file is auto-generated; do not edit it manually
## Adding New Migrations
1. Create a new file: `veza-backend-api/migrations/NNN_description.sql`
2. Use the next available number (check existing migrations)
3. Write idempotent SQL when possible (e.g. `IF NOT EXISTS`)
4. Test locally before committing
5. Run `squash_migrations.sh` to update the baseline for the release