db:migrate

Generate Alembic migration scripts for all features or a single one.

Usage

splent db:migrate [FEATURE] [-m MESSAGE]

Options

Option	Description
`-m`	Migration message (defaults to feature name).

Examples

Migrate all features:

splent db:migrate

Migrate a single feature with a descriptive message:

splent db:migrate splent_feature_notes_tags -m "add tags column to notes"

Description

For each feature (or the specified one), this command:

Generates new migration scripts by comparing the current models against the database schema (alembic revision --autogenerate).
Detects empty migrations (no schema changes) and removes them automatically — preventing accumulation of stub files with only pass.

Each feature uses an isolated Alembic version table named alembic_<feature_name>, so migrations never interfere with each other.

Migration directories are resolved via the product’s features/ symlinks first, falling back to importlib for pip-installed features.

db:migrate only generates migration files — it does not apply them. Use db:upgrade to apply pending migrations after reviewing the generated files.

Refinement features that add columns to a base feature’s table (via mixins) are fully supported. The feature:refine wizard configures the migration scope automatically so that Alembic detects add_column operations on the base table.

Migration order

Migrations are applied in dependency order based on UVL constraints. For example, if profile => auth is declared in the UVL file, auth migrations run before profile.

Migration system

SPLENT uses a per-feature migration layout:

src/splent_io/<feature>/
└── migrations/
    ├── alembic.ini
    ├── env.py
    ├── script.py.mako
    └── versions/

The central tracking table:

CREATE TABLE splent_migrations (
    feature        VARCHAR(255) NOT NULL,
    last_migration VARCHAR(255) DEFAULT NULL,
    PRIMARY KEY (feature)
);

Requirements

SPLENT_APP must be set.
The database must be reachable.
The feature must have a migrations/ directory.