Database
These commands work on the selected product’s database. Each feature owns its Alembic migrations in its own migrations/ folder and its own version table, alembic_<feature>. The splent_migrations table records the last revision applied to each feature. Per-feature migration system explains the layout.
| Command | What it does |
|---|---|
db:migrate |
Writes migration scripts from your model changes |
db:upgrade |
Applies the pending migrations |
db:rollback |
Rolls back a feature’s migrations |
db:status |
Shows the applied and the latest revision of each feature |
db:reset |
Drops every table, or one feature’s, and migrates again |
db:console |
Opens a MariaDB console |
db:dump |
Writes a SQL dump |
db:seed |
Fills the database from the seeders |
db:restore |
Loads a SQL dump |
storage:migrate |
Moves each feature’s files into its own storage folder |
db:migrate, db:upgrade, db:reset and db:seed visit the features in the UVL dependency order that feature:order shows.
Where they run
db:migrate, db:upgrade, db:rollback, db:status, db:reset, db:seed and storage:migrate build the product’s app, which imports every feature and the packages they declare. The product’s image installs those packages, and the CLI’s image only has the framework’s.
When a feature needs a package the CLI container lacks, the command runs in the product’s web container and prints there. If that container is stopped, the command names the missing package and asks you to start the product first.
Error: my_first_app's features need qrcode, which the product's image installs and the CLI's does not.
Start the product (splent product:up --dev) and run the command again: it then runs in the product's web container.
The commands a feature contributes (feature:<name> ...) follow the same rule. Set SPLENT_DEBUG=1 to see what the build logged in the CLI container.