State guards
Table of contents
Introduction
The CLI refuses to remove a feature whose migrations are applied, and it moves features forward on its own when the work behind a state is done. That keeps your database from holding tables no feature owns.
splent db:rollback splent_feature_notes --steps 999
splent feature:remove splent_feature_notes
Roll the feature’s migrations back first, then remove it.
What is blocked
| Command | Blocked in state | Bypass |
|---|---|---|
feature:remove |
migrated | --force |
feature:detach |
migrated | --force |
Both also refuse while another declared feature requires this one, with the same --force. Active is never a blocker, since every feature in use is active.
feature:upgrade has no state guard. It goes through only when the new version keeps every migration of the pinned one with the same parents, so db:upgrade then applies the new ones. See feature:upgrade. feature:unlock and feature:rename run no state check.
What moves on its own
| Trigger | Transition |
|---|---|
00_install_features.sh installs the feature |
declared to installed |
db:upgrade or db:reset succeeds |
declared or installed to migrated |
| The app loads the feature | migrated to active, or any state to active for a feature without migrations |
A full db:rollback |
migrated to installed |
product:resolve |
new entries to declared |
A feature never becomes active before it is migrated, unless it has no migrations/ directory.