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

1.4 KiB

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

# 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