Files
calminer/docs/migrations/consolidated_baseline_plan.md
zwitschi dd3f3141e3
Some checks failed
Run Tests / test (push) Failing after 5m2s
feat: Add currency management feature with CRUD operations
- Introduced a new template for currency overview and management (`currencies.html`).
- Updated footer to include attribution to AllYouCanGET.
- Added "Currencies" link to the main navigation header.
- Implemented end-to-end tests for currency creation, update, and activation toggling.
- Created unit tests for currency API endpoints, including creation, updating, and activation toggling.
- Added a fixture to seed default currencies for testing.
- Enhanced database setup tests to ensure proper seeding and migration handling.
2025-10-25 15:44:57 +02:00

3.6 KiB

Consolidated Migration Baseline Plan

This note outlines the content and structure of the planned baseline migration (scripts/migrations/000_base.sql). The objective is to capture the currently required schema changes in a single idempotent script so that fresh environments only need to apply one SQL file before proceeding with incremental migrations.

Guiding Principles

  1. Idempotent DDL: Every CREATE or ALTER statement must tolerate repeated execution. Use IF NOT EXISTS guards or existence checks (information_schema) where necessary.
  2. Order of Operations: Create reference tables first, then update dependent tables, finally enforce foreign keys and constraints.
  3. Data Safety: Default data seeded by migrations should be minimal and in ASCII-only form to avoid encoding issues in various shells and CI logs.
  4. Compatibility: The baseline must reflect the schema shape expected by the current SQLAlchemy models, API routes, and seeding scripts.

Schema Elements to Include

1. currency Table

  • Columns: id SERIAL PRIMARY KEY, code VARCHAR(3) UNIQUE NOT NULL, name VARCHAR(128) NOT NULL, symbol VARCHAR(8), is_active BOOLEAN NOT NULL DEFAULT TRUE.
  • Index: implicit via unique constraint on code.
  • Seed rows matching scripts.seed_data.CURRENCY_SEEDS (ASCII-only symbols such as USD$, CAD$).
  • Upsert logic using ON CONFLICT (code) DO UPDATE to keep names/symbols in sync when rerun.

2. Currency Integration for CAPEX/OPEX

  • Add currency_id INTEGER columns with IF NOT EXISTS guards.
  • Populate currency_id from legacy currency_code if the column exists.
  • Default null currency_id values to the USD row, then ALTER to SET NOT NULL.
  • Create fk_capex_currency and fk_opex_currency constraints with ON DELETE RESTRICT semantics.
  • Drop legacy currency_code column if it exists (safe because new column holds data).

3. Measurement Metadata on Consumption/Production

  • Ensure consumption and production_output tables have unit_name VARCHAR(64) and unit_symbol VARCHAR(16) columns with IF NOT EXISTS guards.

4. measurement_unit Reference Table

  • Columns: id SERIAL PRIMARY KEY, code VARCHAR(64) UNIQUE NOT NULL, name VARCHAR(128) NOT NULL, symbol VARCHAR(16), unit_type VARCHAR(32) NOT NULL, is_active BOOLEAN NOT NULL DEFAULT TRUE, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW().
  • Assume a simple trigger to maintain updated_at is deferred: automate via application layer later; for now, omit trigger.
  • Seed rows matching MEASUREMENT_UNIT_SEEDS (ASCII names/symbols). Use ON CONFLICT (code) DO UPDATE to keep descriptive fields aligned.

5. Transaction Handling

  • Wrap the main operations in a single BEGIN; ... COMMIT; block.
  • Use subtransactions (DO $$ ... $$;) only where conditional logic is required (e.g., checking column existence before backfill).

Migration Tracking Alignment

  • Baseline file will be named 000_base.sql. After execution, insert a row into schema_migrations with filename 000_base.sql to keep the tracking table aligned.
  • Existing migrations (20251021_add_currency_and_unit_fields.sql, 20251022_create_currency_table_and_fks.sql) remain for historical reference but will no longer be applied to new environments once the baseline is present.

Next Steps

  1. Draft 000_base.sql reflecting the steps above.
  2. Update run_migrations to recognise the baseline file and mark older migrations as applied when the baseline exists.
  3. Provide documentation in docs/quickstart.md explaining how to reset an environment using the baseline plus seeds.